linux-kernel - Commit Links [was: Linux 6.17-rc5]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ef8479be-8bac-42c5-bac6-5a5841959b45@kernel.org>
Date: Fri, 12 Sep 2025 08:24:06 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Commit Links [was: Linux 6.17-rc5]

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