Message-ID: <aMg9WjipgDtgVPIR@google.com>
Date: Mon, 15 Sep 2025 09:22:50 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: "Uwe Kleine-König" <u.kleine-koenig@...libre.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Jiri Slaby <jirislaby@...nel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Commit Links [was: Linux 6.17-rc5]

On Mon, Sep 15, 2025, Uwe Kleine-König wrote:
> Hello Linus,
> 
> On Fri, Sep 12, 2025 at 08:24:06AM +0200, Jiri Slaby wrote:
> > On 08. 09. 25, 0:25, Linus Torvalds wrote:
> > > So please: don't add useless information to commits in general, but in
> > > _particular_ don't add "Link:" tags that only point back to the
> > > original submission email. Yes, we have tooling that does it
> > > automatically, but tooling should not be used to increase the human
> > > burden. Tooling should _help_, not hurt.
> > 
> > I disagree. In a bug-reporter role, I use these Links pointing to the
> > patches every time. So unless there is a way (I did not find one), they are
> > very useful.
> > 
> > My use case is (mostly) dig out the thread/patch (grep Link, and b4 or
> > https://lore.kernel.org/all -> raw) and reply to it as it causes some issue.
> > 
> > In a backporter role, I use the Links to look at the thread to see the
> > _whole_ patchset instead of guess work from the linear commit log.
> 
> +1, after a bisection I typically lookup the thread, too, to have my
> regression report in the right thread. IMHO this is really useful
> because the next person hitting the same problem (maybe?) finds my
> report easily. So for me the Link trailer is useful, too.

I described several other scenarios where the source/submitted link is useful
last time this came up[*], along with the same proposal to have a dedicated
trailer so that people that don't want to risk exploring what might be a dead
end can more easily ignore that specific link.

[*] https://lore.kernel.org/all/Z-2XVMOJXUjVYXV0@google.com

> > > Make the links be something *useful*. Make them point to the report
> > > for the bug that was the cause of the commit. Make them point to the
> > > discussion that explains the impetus for the commit. But do *not*
> > > mindlessly just use tooling to create a link that doesn't add anything
> > > that isn't already right there in the commit.
> > > 
> > > I realize that people think the link makes the commit look more "real"
> > > or whatever. And I've heard people claim that discussion happens later
> > > in the thread that the link points to. Neither of those are actually
> > > true. When bugs happen, people don't go to the original emailed patch
> > > to talk about them. Much of the time the reporter can't even tell
> > > which patch caused it - and if they did bisect it, we already have the
> > > information - there's no value add in going back to the original
> > > emailed patch.
> 
> The true fact is probably that *most* people don't go back to the email
> thread to reply there (either because the breaking commit isn't known
> yet or they just start a new thread). Yes, the few who do can probably
> easily lookup the thread on lore, but clicking on a link is easier (and
> makes sure you find the version of the patch that was applied and not
> an earlier version). (Or a later version that the maintainer failed to
> notice before applying an earlier version.)
> 
> > > So if a link doesn't have any extra relevant information in it, just
> > > don't add it at all in some misguided hope that tomorrow it will be
> > > useful.
> > > 
> > > Make "Link:" tags be something to celebrate, not something to curse
> > > because they are worthless and waste peoples time.
> 
> What will you do if a question arises on a commit without a Link:
> trailer? I guess you will lookup the shortlog on lore?
> If the Link trailer was skipped because there is no relevant discussion
> in the thread that resulted in application of the patch, you will still
> look at it, just taking more time to eventually find it. So while I
> agree this is a dead end with and without Link: most of the time, not
> adding the Link: doesn't prevent you exploring that dead end, but only
> results in more effort to find it.

Powered by blists - more mailing lists