mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Commit Links [was: Linux 6.17-rc5]
Date: Fri, 12 Sep 2025 08:24:06 +0200	[thread overview]
Message-ID: <ef8479be-8bac-42c5-bac6-5a5841959b45@kernel.org> (raw)
In-Reply-To: <CAHk-=wh5AyuvEhNY9a57v-vwyr7EkPVRUKMPwj92yF_K0dJHVg@mail.gmail.com>

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.

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

OK, can we have Submitted-at: or something for the above which you could 
completely ignore?

Actually we have Closes:. So should you look at Closes instead and 
ignore Link? Like for example in 92bac7d4de9c0.

I know, there is no standardization and different people use Links for 
different purpose, so perhaps we unify/document all those and drop Link 
completely? (Ie. having Closes, Submitted-at or such?)

thanks,
-- 
js
suse labs


  parent reply	other threads:[~2025-09-12  6:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-07 22:25 Linux 6.17-rc5 Linus Torvalds
2025-09-09  0:50 ` Guenter Roeck
2025-09-09 15:27   ` Brian Norris
2025-09-12  6:24 ` Jiri Slaby [this message]
2025-09-12 19:14   ` Commit Links [was: Linux 6.17-rc5] Al Viro
2025-09-12 22:22   ` Linus Torvalds
2025-10-13  8:53     ` Jiri Slaby
2025-09-15  8:16   ` Uwe Kleine-König
2025-09-15 16:22     ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ef8479be-8bac-42c5-bac6-5a5841959b45@kernel.org \
    --to=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®