Message-ID: <4iceeja4kbnb4cir26kme6z6wabnnyu6trc2qo7ye7po65wemr@i2tyg7cfq54x>
Date: Mon, 15 Sep 2025 10:16:08 +0200
From: Uwe Kleine-König <u.kleine-koenig@...libre.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jiri Slaby <jirislaby@...nel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Commit Links [was: Linux 6.17-rc5]

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.
 
> > 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.

Best regards
Uwe

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists