* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 17:00 ` Linus Torvalds
@ 2025-10-13 18:14 ` Paolo Bonzini
2025-10-13 18:53 ` Linus Torvalds
2025-10-13 21:59 ` Theodore Ts'o
` (2 subsequent siblings)
3 siblings, 1 reply; 81+ messages in thread
From: Paolo Bonzini @ 2025-10-13 18:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michael S. Tsirkin, Konstantin Ryabitsev, users, tools
Hi Linus!
On Mon, Oct 13, 2025 at 7:00 PM Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
> My fundamental complaint is actually about the "mindless" part. And
> that' entirely unrelated to whether you call it "Link", "Message-ID",
> or anything else.
>
> I object *strongly* to any random noise that doesn't add explicit
> value.
I understand why you jumped in the middle; if you want to read it I
explained in the first message what value it adds, but I'll reply to
your point about automation specifically.
> But if it's automated and mindless and you're not thinking about it,
> it damn well remains wrong whether the "Link" part is renamed or not.
> Every single commit already fundamentally has sufficient information
> to find the submission
Yes, it's automated and mindless, but it's there *so that no one has
to think about it later*. Other information may be sufficient but the
point is that you don't have to "find" anything, and a click takes you
from git to lore, which for me are two views of the same world. Even
with "b4 dig" there are *many* extra steps compared to a click.
It may be something that you almost never do, because you interact
with people mostly via their pull requests, so perhaps your workflow
is quite fundamentally different? For a lot of us it's a very common
task to look up individual patch submissions from other subsystems,
and to reference or review them after the fact, and the message id is
*guaranteed correct*.
On top of this, the message id indirectly serves as an annotation for
series boundaries, since everybody is using "git send-email" which has
a constant format. It may not be the most precise thing but it is
surprisingly useful---and as explained in the top message, what you
want here is something that both humans and programs can use, either
as a starting point for analysis, or to spot-check common mistakes. An
alternative here could be to give a merge commit to each series, which
for example the KVM ARM tree does, but then merge commits are not
easily consumed by scripts.
> What's the real argument against "b4 dig"?
There's no argument against it as a tool. It's useful as a fallback
(there are always going to be commits with missing message-id,
especially simple patches committed by maintainers themselves), and
I'd love for it to develop "git range-diff"-like functionality too. I
think I'd prefer it as a browser interface that starts the exploration
from say https://lore.kernel.org/dig/COMMITID, though, but maybe
others prefer a not-pointy-clicky interface.
But you don't have to use the same tool for the easy and hard cases.
b4 dig is a tool for the hard case; Message-id, when present, is exact
information about the commit, and it serves *easily* multiple
workflows. Why discard useful metadata and then require tools to
reconstruct it?
Thanks,
Paolo
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 18:14 ` Paolo Bonzini
@ 2025-10-13 18:53 ` Linus Torvalds
2025-10-13 20:12 ` Junio C Hamano
2025-10-13 22:31 ` Paolo Bonzini
0 siblings, 2 replies; 81+ messages in thread
From: Linus Torvalds @ 2025-10-13 18:53 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Michael S. Tsirkin, Konstantin Ryabitsev, users, tools
On Mon, 13 Oct 2025 at 11:14, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> Yes, it's automated and mindless, but it's there *so that no one has
> to think about it later*. Other information may be sufficient but the
> point is that you don't have to "find" anything, and a click takes you
> from git to lore, which for me are two views of the same world. Even
> with "b4 dig" there are *many* extra steps compared to a click.
So the main argument is literally the "click" vs "command line"?
Because this argument is clearly garbage:
> and to reference or review them after the fact, and the message id is
> *guaranteed correct*.
No. The message id is one random message among potentially multiple versions.
There is no "guaranteed correct" about it. It may be *unique*, but if
there are multiple copies of that same patch floating about, that does
not make one of them more "correct", and not seeing that there were
other versions might well be just hiding other relevant information.
I see the same patch series several times, and I see people add
reviews etc on one version, and then those tags are (hopefully) taken
into account in the next version, but generally when that next version
is pasted, the thread on the first one is *not* part of the next
version that is posted.
So your "guaranteed correct" link is really just "guaranteed unique".
And not in a particularly good way.
> On top of this, the message id indirectly serves as an annotation for
> series boundaries, since everybody is using "git send-email" which has
> a constant format.
Ok, that's just strange. That's not how any of this should work.
I do wish more people used merges for series and put the series cover
letter in the merge message. Now *that* would be a real improvement
for bigger series.
Arguing for parsing the message ID as some kind of series thing is just sick.
Anyway, I can see the "click vs command line", although the only tool
I personally use where that would make a difference is "gitk".
But I assume you use some terminal or IDE that auto-converts text to
links for you? I just cut-and-paste regardless, so I don't see that
issue.
Linus
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 18:53 ` Linus Torvalds
@ 2025-10-13 20:12 ` Junio C Hamano
2025-10-13 21:44 ` Linus Torvalds
2025-10-13 22:31 ` Paolo Bonzini
1 sibling, 1 reply; 81+ messages in thread
From: Junio C Hamano @ 2025-10-13 20:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Paolo Bonzini, Michael S. Tsirkin, Konstantin Ryabitsev, users,
tools
Linus Torvalds <torvalds@linuxfoundation.org> writes:
> I do wish more people used merges for series and put the series cover
> letter in the merge message. Now *that* would be a real improvement
> for bigger series.
Perhaps something like
#1 "git am" learns an option to apply patches [1/47], [2/47],
[3/47], ..., [47/47] in order, and then [0/47] as an empty
commit to record the cover letter on top of that series;
#2 "git merge topic" notices such a topic capped with an empty
commit that records the cover letter, and merges "topic~1" and
throws the log message of "topic~0" in the log message for the
merge commit;
#3 "git format-patch" learns an option to take a topic branch that
is shaped what "git am" would have produced in #1 (i.e. you fork
a topic, build commits [1/47], [2/47], ..., [47/47], and capped
with an empty commit with the cover letter material, and does
the obvious inverse of #1.
would make the world slightly a better place?
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 20:12 ` Junio C Hamano
@ 2025-10-13 21:44 ` Linus Torvalds
2025-10-13 23:22 ` Sasha Levin
2025-10-14 3:39 ` Willy Tarreau
0 siblings, 2 replies; 81+ messages in thread
From: Linus Torvalds @ 2025-10-13 21:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Paolo Bonzini, Michael S. Tsirkin, Konstantin Ryabitsev, users,
tools
On Mon, 13 Oct 2025 at 13:12, Junio C Hamano <junio@pobox.com> wrote:
>
> Perhaps something like
>
> #1 "git am" learns an option to apply patches [1/47], [2/47],
> [3/47], ..., [47/47] in order, and then [0/47] as an empty
> commit to record the cover letter on top of that series;
So b4 - which is the "lore helper around git" - actually has something
like this whole sequence. See
https://b4.docs.kernel.org/en/latest/maintainer/am-shazam.html
So "b4 am" will download the series from lore, ready to be applied
with "git am". That is - I think - the most common sequence for most
people.
But "b4 shazam" will do both the "figure out series" and then download
it, and has a "-M" option to them merge the end result.
And people do use it, although it's not all that common. The
networking tree tends to have lots of those kinds of series, but
outside of that tree it's _fairly_ unusual.
The latest example of this kind of thing in the kernel I found was
gitk cfc584537150^..cfc584537150
but I don't actually know if Nathan used "b4 shazam" for this, or
whether he just did it all by hand and actually had separate branches.
I think one issue is that a lot of people feel more comfortable with
linear series of patches, and already have tooling around that kind of
plain patch series.
Another issue is that it does require some actual thought - it would
be silly and counter-productive to do for singleton patches (which are
fairly common), and likely still silly for things that are two or
three patches unless there really is some kind of "overarching
explanation" that makes sense.
Because often it's just simpler and more straightforward to explain
those kinds of small series as individual patches, and the
cover-letter (and the merge) just wouldn't add a whole lot of value,
and only makes the whole thing a bit more complicated.
It also means that once you've applied it with a merge around it, you
need to be careful if you end up going back and amending the commits
for new review tags (or typos, or other "trivial everyday things" that
always tend to happen).
So you need to keep things like "git rebase --keep-merges" in mind, so
it's not like it turns things unmanageable, but the merge model does
have real complexities.
What I think might actually work *better* is to have some help for
fixing things up later.
For example, while I think that a "git rebase --keep-merges" workflow
is a bit scary and opens you up to lots of possible things going
wrong, having some way for "git rebase -i" to *add* merges
interactively might be a nice option.
I've personally had the situation where I created some series of
patches and wanted to group them later. What I would do is then create
a different branch, rebase the patches I wanted to keep in one series
in that branch, and then go back, and rebase the original branch with
the remaining commits.
That works fine. And there's nothing wrong with that flow, I think.
But I tend to get pull requests from Andrew (and some other people,
but Andrew is perhaps the most consistent case), which typically
contain a series of series that Andrew has been building up for some
time.
And then Andrew explains those as
- series of X patches doing ABC
- series of Y patches doing GHI
.. and so on.
And because I personally find the "series of N patches" part to be not
only repetitive, but think it kind of distracts from the *important*
thing (which is what the patches do, not how many there are), I
actually typically edit that "N patches" part out.
Now, I think often having separate branches for all those things would
be fine, *but* there are often singletons in there where a separate
branch would only be pointless extra work.
And more importantly when it's somebody like Andrew, the series may be
"conceptually independent", but they are often all in the same area,
so they might all be MM - and they will thus often in practice have
some interaction with each other.
Having a linear series of patches delimited by merges to group them
and document them would probably work really well, but it would need
to fit in with all the other tools, and as mentioned, many tools
really do just do "patch series".
I suspect Andrew still not only uses git _as_ a patch series
maintenance tool, but probably together with the patch series scripts
he has used for decades, and he removes/edits/reorders/squashes
patches in the middle etc.
What this is all leading up to is that I suspect a more palatable
workflow might be to "fix things later with git rebase".
Because I personally think I'd use something like "git rebase -i"
together with a way to delineate patches by adding merges at *that*
point.
So rather than doing a separate branch, rebasing things there, and
going back and rebasing away the things in my original branch, doing
just 'git rebase -i" in the original branch and having some way to say
"this is the start of this series", and a "this is the end of the
series", and having git rebase create a set of linear series with
merges that delineate them might be quite convenient.
I say that without having actually tried it, but from a "I think I
would have found that useful in several situations" kind of way.
Linus
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 21:44 ` Linus Torvalds
@ 2025-10-13 23:22 ` Sasha Levin
2025-10-14 1:29 ` Linus Torvalds
2025-10-14 3:39 ` Willy Tarreau
1 sibling, 1 reply; 81+ messages in thread
From: Sasha Levin @ 2025-10-13 23:22 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Paolo Bonzini, Michael S. Tsirkin,
Konstantin Ryabitsev, users, tools
On Mon, Oct 13, 2025 at 02:44:28PM -0700, Linus Torvalds wrote:
>For example, while I think that a "git rebase --keep-merges" workflow
>is a bit scary and opens you up to lots of possible things going
>wrong, having some way for "git rebase -i" to *add* merges
>interactively might be a nice option.
>
>I've personally had the situation where I created some series of
>patches and wanted to group them later. What I would do is then create
>a different branch, rebase the patches I wanted to keep in one series
>in that branch, and then go back, and rebase the original branch with
>the remaining commits.
[...]
>Having a linear series of patches delimited by merges to group them
>and document them would probably work really well, but it would need
>to fit in with all the other tools, and as mentioned, many tools
>really do just do "patch series".
[...]
>So rather than doing a separate branch, rebasing things there, and
>going back and rebasing away the things in my original branch, doing
>just 'git rebase -i" in the original branch and having some way to say
>"this is the start of this series", and a "this is the end of the
>series", and having git rebase create a set of linear series with
>merges that delineate them might be quite convenient.
I'm using such workflow for my backporting work: I often want to group the
patch I'm backporting along with it's dependencies into a single "atomic" unit
to make it easier to review those changes later.
It currently uses hackery like the one you've described. Something like this:
N=$1
saved=$(git rev-parse HEAD)
temp="tmp-triangle-$(date +%s)"
git branch $temp $saved
git reset --hard HEAD~$N
git merge --no-ff -m "${2:-Merge triangle of last $N commits}" $temp
git branch -D $temp
Which creates a structure such as:
$ git log -5 --oneline --graph 11faed99eb
* 11faed99eb030 FAILED: 64e0d839c589 ("mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag")
|\
| * 3bc90aaf9933e mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag
| * 08b4fd511c7f9 mfd: intel_soc_pmic_chtdc_ti: Drop unneeded assignment for cache_type
| * f6d0ec2c9ccb4 mfd: intel_soc_pmic_chtdc_ti: Fix invalid regmap-config max_register value
|/
* 2b2cbdcede387 (tag: v6.12.52, stable/linux-6.12.y) Linux 6.12.52
If you want to use it as part of your git-rebase workflow, just call the script during rebase:
pick c3c4268124d22 # kbuild: Use '--strip-unneeded-symbol' for removing module device table symbols
pick 4ee16af35eb65 # tracing: Fix tracing_mark_raw_write() to use buf and not ubuf
pick 88d5c7c180dfc # tracing: Stop fortify-string from warning in tracing_mark_raw_write()
x stable-make-triangle 2
pick ed5afe51ba32e # irqchip/aspeed-scu-ic: Fix an IS_ERR() vs NULL check
pick 89d38b0392fa4 # irqchip/sifive-plic: Avoid interrupt ID 0 handling during suspend/resume
pick 3897851fae349 # Revert "i2c: boardinfo: Annotate code used in init phase only"
pick 49a451202c681 # Linux 6.18-rc1
Which results in something like what you were looking for?
$ git log --oneline --graph -10
* 53cb9bf28b1b7 (HEAD) Linux 6.18-rc1
* d6f9a71712aff Revert "i2c: boardinfo: Annotate code used in init phase only"
* 8943a4934a860 irqchip/sifive-plic: Avoid interrupt ID 0 handling during suspend/resume
* 12257b8fccebf irqchip/aspeed-scu-ic: Fix an IS_ERR() vs NULL check
* decf0198935a6 Merge triangle of last 2 commits
|\
| * 88d5c7c180dfc tracing: Stop fortify-string from warning in tracing_mark_raw_write()
| * 4ee16af35eb65 tracing: Fix tracing_mark_raw_write() to use buf and not ubuf
|/
* c3c4268124d22 kbuild: Use '--strip-unneeded-symbol' for removing module device table symbols
* 0f43fbd0b759c s390/vmlinux.lds.S: Move .vmlinux.info to end of allocatable sections
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 23:22 ` Sasha Levin
@ 2025-10-14 1:29 ` Linus Torvalds
0 siblings, 0 replies; 81+ messages in thread
From: Linus Torvalds @ 2025-10-14 1:29 UTC (permalink / raw)
To: Sasha Levin
Cc: Junio C Hamano, Paolo Bonzini, Michael S. Tsirkin,
Konstantin Ryabitsev, users, tools
On Mon, 13 Oct 2025 at 16:22, Sasha Levin <sashal@kernel.org> wrote:
>
> If you want to use it as part of your git-rebase workflow, just call the script during rebase:
Yeah, I've used 'exec' tricks too, but not for this particular case,
and I do think your script is particularly hacky.
IOW, having an interactive rebase thing like this:
> pick c3c4268124d22 # kbuild: Use '--strip-unneeded-symbol' for removing module device table symbols
> pick 4ee16af35eb65 # tracing: Fix tracing_mark_raw_write() to use buf and not ubuf
> pick 88d5c7c180dfc # tracing: Stop fortify-string from warning in tracing_mark_raw_write()
> x stable-make-triangle 2
certainly "works", but doesn't strike me as a particularly good way to
sayt "group those two last things into one 'merge group'".
This is something git rebase probably _could_ have some nicer active
support for.
At a minimum, I'd say that the rebase scripting should have something
where you can delineate the start/end points in a legible manner.
But I do find it interesting that you actually do already use that
workflow I outlined, and I do think it's worth looking into, I just
think your particular 'stable-make-triangle' script is a bit _too_
esoteric as an interface ;)
Linus
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 21:44 ` Linus Torvalds
2025-10-13 23:22 ` Sasha Levin
@ 2025-10-14 3:39 ` Willy Tarreau
2025-10-16 14:52 ` Geert Uytterhoeven
1 sibling, 1 reply; 81+ messages in thread
From: Willy Tarreau @ 2025-10-14 3:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Paolo Bonzini, Michael S. Tsirkin,
Konstantin Ryabitsev, users, tools
On Mon, Oct 13, 2025 at 02:44:28PM -0700, Linus Torvalds wrote:
> So rather than doing a separate branch, rebasing things there, and
> going back and rebasing away the things in my original branch, doing
> just 'git rebase -i" in the original branch and having some way to say
> "this is the start of this series", and a "this is the end of the
> series", and having git rebase create a set of linear series with
> merges that delineate them might be quite convenient.
FWIW I'm using "git rebase -i" a lot, that's probably the command that
really makes git magical from the developer's perspective. While I know
it's possible to keep empty commits, it"s usually not welcome because
the purpose of rebases is to be able to rework a series by moving things
around and eliminate those that have been nicely integrated.
Thus I think that what would really be nice (and that I've been missing
many times) is a type of commit that git recognizes as a delimiter, i.e.
it doesn't contain data, but *something* (maybe a dummy diff on /dev/null
vs itself?) allows git rebase and git am to say "OK that's not the regular
empty commit, it's one I have to keep anyway". Then one specific option
of git am or git rebase could be used to turn that commit into a merge
one.
This would allow to keep the history linear the for the longest possible
time with cover patches at the end (or maybe the beginning, like 0/X),
it would ease running git am on a patch series starting at zero, and
would let the merge commit be created at the final point, maybe even
just on the side of the final recipient (you in your case).
> I say that without having actually tried it, but from a "I think I
> would have found that useful in several situations" kind of way.
I'm one of those. On projects moving slower than the kernel, it's easy
to avoid merge commits and keep the history linear for easier backports,
but clearly series delimiters are missing.
Thanks,
Willy
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-14 3:39 ` Willy Tarreau
@ 2025-10-16 14:52 ` Geert Uytterhoeven
2025-10-16 15:08 ` Jason Gunthorpe
0 siblings, 1 reply; 81+ messages in thread
From: Geert Uytterhoeven @ 2025-10-16 14:52 UTC (permalink / raw)
To: Willy Tarreau
Cc: Linus Torvalds, Junio C Hamano, Paolo Bonzini, Michael S. Tsirkin,
Konstantin Ryabitsev, users, tools
Hi Willy,
On Thu, 16 Oct 2025 at 16:37, Willy Tarreau <w@1wt.eu> wrote:
> On Mon, Oct 13, 2025 at 02:44:28PM -0700, Linus Torvalds wrote:
> > So rather than doing a separate branch, rebasing things there, and
> > going back and rebasing away the things in my original branch, doing
> > just 'git rebase -i" in the original branch and having some way to say
> > "this is the start of this series", and a "this is the end of the
> > series", and having git rebase create a set of linear series with
> > merges that delineate them might be quite convenient.
>
> FWIW I'm using "git rebase -i" a lot, that's probably the command that
> really makes git magical from the developer's perspective. While I know
> it's possible to keep empty commits, it"s usually not welcome because
> the purpose of rebases is to be able to rework a series by moving things
> around and eliminate those that have been nicely integrated.
As the audience may not know: you can keep empty commits while rebasing
using --keep-empty. But it is indeed tedious. So I wrote a script
called git-add-separator, which creates an empty file .separators/L<N>
(N increasing automatically) and commits it, thus creating a non-empty
commit that doesn't interfere much with the rest of my tree.
> Thus I think that what would really be nice (and that I've been missing
> many times) is a type of commit that git recognizes as a delimiter, i.e.
> it doesn't contain data, but *something* (maybe a dummy diff on /dev/null
> vs itself?) allows git rebase and git am to say "OK that's not the regular
> empty commit, it's one I have to keep anyway". Then one specific option
> of git am or git rebase could be used to turn that commit into a merge
> one.
Can be done. Let's try manually:
# Pointing to the "empty" commit with series description
top=$(git show | head -1 | cut -d " ")
# Find previous empty commit
old=...
git reset --hard $old
git merge --no-ff $top~1 -m "$(git show $top | ...)"
OK ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-16 14:52 ` Geert Uytterhoeven
@ 2025-10-16 15:08 ` Jason Gunthorpe
2025-10-16 15:33 ` Geert Uytterhoeven
0 siblings, 1 reply; 81+ messages in thread
From: Jason Gunthorpe @ 2025-10-16 15:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Willy Tarreau, Linus Torvalds, Junio C Hamano, Paolo Bonzini,
Michael S. Tsirkin, Konstantin Ryabitsev, users, tools
On Thu, Oct 16, 2025 at 04:52:31PM +0200, Geert Uytterhoeven wrote:
> As the audience may not know: you can keep empty commits while rebasing
> using --keep-empty. But it is indeed tedious. So I wrote a script
> called git-add-separator, which creates an empty file .separators/L<N>
> (N increasing automatically) and commits it, thus creating a non-empty
> commit that doesn't interfere much with the rest of my tree.
I use empty separator commits all the time, and git rebase -i
alot. Never had a problem, never needed --keep-empty..
Don't see any 'empty' related config in my 'git config -l'
It seems like rebase doesn't remove commits that started out empty, it
removes commits that become empty
?
Jason
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-16 15:08 ` Jason Gunthorpe
@ 2025-10-16 15:33 ` Geert Uytterhoeven
0 siblings, 0 replies; 81+ messages in thread
From: Geert Uytterhoeven @ 2025-10-16 15:33 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Willy Tarreau, Linus Torvalds, Junio C Hamano, Paolo Bonzini,
Michael S. Tsirkin, Konstantin Ryabitsev, users, tools
Hi Jason,
On Thu, 16 Oct 2025 at 17:08, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Thu, Oct 16, 2025 at 04:52:31PM +0200, Geert Uytterhoeven wrote:
> > As the audience may not know: you can keep empty commits while rebasing
> > using --keep-empty. But it is indeed tedious. So I wrote a script
> > called git-add-separator, which creates an empty file .separators/L<N>
> > (N increasing automatically) and commits it, thus creating a non-empty
> > commit that doesn't interfere much with the rest of my tree.
>
> I use empty separator commits all the time, and git rebase -i
> alot. Never had a problem, never needed --keep-empty..
>
> Don't see any 'empty' related config in my 'git config -l'
>
> It seems like rebase doesn't remove commits that started out empty, it
> removes commits that become empty
>
> ?
You are right, empty commits are retained on interactive rebase with
my current git (2.43.0). They used to be shown in the interactive
rebase with a hash mark in front, thus considered a comment, and
dropped.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 18:53 ` Linus Torvalds
2025-10-13 20:12 ` Junio C Hamano
@ 2025-10-13 22:31 ` Paolo Bonzini
2025-10-14 6:47 ` Jiri Slaby
1 sibling, 1 reply; 81+ messages in thread
From: Paolo Bonzini @ 2025-10-13 22:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michael S. Tsirkin, Konstantin Ryabitsev, users, tools
Il lun 13 ott 2025, 20:53 Linus Torvalds <torvalds@linuxfoundation.org>
ha scritto:
>> it's there *so that no one has to think about it later*. Other
>> information may be sufficient but the point is that you don't
>> have to "find" anything. Even with "b4 dig" there are *many*
>> extra steps compared to a click.
>
> So the main argument is literally the "click" vs "command line"?
> Because this argument is clearly garbage:
>
>> and to reference or review them after the fact, and the message
>> id is *guaranteed correct*.
>
> No. The message id is one random message among potentially multiple
> versions.
It's literally the one that was applied, which makes it the right
starting point for interacting with the authors (the easy/common case of
reporting a bug) and *also* a good one for analyzing the history. This
is something that multiple people have said they are missing, right in
this thread or elsewhere.
I agree that there could be >1 message for that *patch* and that
precious information could be hidden in earlier version. But you're
focusing on the hard case. For many people (especially bug reporters)
all that matters is to have an easy point of contact between the git
world and the mailing list world. And for people sitting between you and
bug reporters, that's the case that we want to set up.
> There is no "guaranteed correct" about it. It may be *unique*, but
> if there are multiple copies of that same patch floating about,
> that does not make one of them more "correct", and not seeing that
> there were other versions might well be just hiding other relevant
> information.
>
> So your "guaranteed correct" link is really just "guaranteed
> unique". And not in a particularly good way.
I'm not clear on what makes it not a good way? For me it's an effective
entry point for the easy case. For the hard case there's "b4 dig", or
Patchew that I put together a few years ago[1].
>> On top of this, the message id indirectly serves as an annotation
>> for series boundaries, since everybody is using "git send-email"
>> which has a constant format.
>
> Ok, that's just strange. That's not how any of this should work.
> [...] Arguing for parsing the message ID as some kind of series
> thing is just sick.
Can't deny that but it gets the job done. I am sure I am not the only
one to do that. When working on/with backports (either kernel.org stable
trees or distro stuff), a quick check of the message ids works
ridiculously well to catch screwups, or to remind me to tell reviewers
why I left out a patch. It brings 99% of the accuracy with 1% of the
effort, which makes me forget it's sick.
The point is that it's versatile and people have multiple uses for it...
One person's trash is another person's treasure.
> But I assume you use some terminal or IDE that auto-converts text
> to links for you?
Yep, it's a terminal emulator (Tilix) that can make any regular
expression match clickable, and will run a command to "open" it[2]. That
may explain why I like Message-Id trailers. :) But at least clickable
URLs should be pretty universal?
Paolo
[1] https://patchew.org/linux/cover.1760368250.git.leon@kernel.org/
[2] https://gnunn1.github.io/tilix-web/manual/customlinks/
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 22:31 ` Paolo Bonzini
@ 2025-10-14 6:47 ` Jiri Slaby
0 siblings, 0 replies; 81+ messages in thread
From: Jiri Slaby @ 2025-10-14 6:47 UTC (permalink / raw)
To: Paolo Bonzini, Linus Torvalds
Cc: Michael S. Tsirkin, Konstantin Ryabitsev, users, tools
On 14. 10. 25, 0:31, Paolo Bonzini wrote:
> Il lun 13 ott 2025, 20:53 Linus Torvalds <torvalds@linuxfoundation.org>
> ha scritto:
>>> it's there *so that no one has to think about it later*. Other
>>> information may be sufficient but the point is that you don't
>>> have to "find" anything. Even with "b4 dig" there are *many*
>>> extra steps compared to a click.
>>
>> So the main argument is literally the "click" vs "command line"?
>> Because this argument is clearly garbage:
>>
>>> and to reference or review them after the fact, and the message
>>> id is *guaranteed correct*.
>>
>> No. The message id is one random message among potentially multiple
>> versions.
>
> It's literally the one that was applied, which makes it the right
> starting point for interacting with the authors (the easy/common case of
> reporting a bug) and *also* a good one for analyzing the history. This
> is something that multiple people have said they are missing, right in
> this thread or elsewhere.
Exactly, and I still fail to see the reason in building up this very
barrier between bug reporters and developers. Using Link: (or whatever
tag) is so easy for everyone -- that's actually why every second one
started using it. And works in 99™ % cases (for me at least).
Installing b4 is a real barrier, particularly. Now moreover, it has to
be new enough, namely a snapshot (look at repology what versions of b4
are in distros). And in fact, it does not even give one what they want
to get.
>> So your "guaranteed correct" link is really just "guaranteed unique".
>> And not in a particularly good way.
>
> I'm not clear on what makes it not a good way? For me it's an effective
> entry point for the easy case. For the hard case there's "b4 dig", or
> Patchew that I put together a few years ago[1].
Using anything more than click a Link is more work to be done anyway.
And I resist to spend it when I actually don't have to.
>> But I assume you use some terminal or IDE that auto-converts text
>> to links for you?
>
> Yep, it's a terminal emulator (Tilix) that can make any regular
> expression match clickable,
Yes, like many sane terminals nowadays. Konsole in my case (without
actually setting up anything special, just open "git log" and
right-click, left-click).
So even if I had capable b4, I concur this might be helpful for people:
$ b4 dig -c 23743ba64709
Digging into commit 23743ba64709a9c137c1b928f8b8e00d846af9cc
Attempting to match by exact patch-id...
Trying to find matching series by patch-id
c3157dfd330b6951d93ff0a0e35f5a09b0e05c85
Grabbing search results from lore.kernel.org
Found matching series by patch-id
---
This patch is present in the following series:
---
v1: [PATCH] vt: add support for smput/rmput escape codes
https://lore.kernel.org/r/20250824142016.47219-1-calixte.pernot@grenoble-inp.org
v2: [PATCH v2] vt: add support for smput/rmput escape codes
https://lore.kernel.org/r/20250825125607.2478-3-calixte.pernot@grenoble-inp.org
v3: [PATCH v3] vt: add support for smput/rmput escape codes
https://lore.kernel.org/r/20250909202629.9386-2-calixte.pernot@grenoble-inp.org
But for me, where am I supposed to reply to when I want to comment on
23743ba64709? Hint: it's not that v3. So I have to open them and read?
Hmm, isn't it exactly what you, Linus, hate?
Similarly, if I were to backport 23743ba64709, where can I look for the
whole series which this patch can be a part of?
The output is helpful, but not for our usecases...
thanks,
--
js
suse labs
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 17:00 ` Linus Torvalds
2025-10-13 18:14 ` Paolo Bonzini
@ 2025-10-13 21:59 ` Theodore Ts'o
2025-10-13 23:09 ` Michael S. Tsirkin
2025-10-15 7:33 ` Geert Uytterhoeven
3 siblings, 0 replies; 81+ messages in thread
From: Theodore Ts'o @ 2025-10-13 21:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael S. Tsirkin, Paolo Bonzini, Konstantin Ryabitsev, users,
tools
On Mon, Oct 13, 2025 at 10:00:01AM -0700, Linus Torvalds wrote:
> What's the real argument against "b4 dig"?
At the moment:
https://goomics.net/50
"There are two ways of doing things at Google; the deprecated way
(e.g., Link Tag), and the one which isn't ready yet." :-)
It's *close*, and it's not yet available to most developers unless
they are running out of b4's git HEAD. I did try using it on a
selection of patches, and I was pleasantly surprised how often it
worked. But it's definitely not perfect. For example:
% /usr/projects/linux/b4/b4.sh dig -c 1d3ad183943b38eec2acf72a0ae98e635dc8456b
Digging into commit 1d3ad183943b38eec2acf72a0ae98e635dc8456b
Attempting to match by exact patch-id...
Trying to find matching series by patch-id 7f91856ff1f9b87a4fcaf69134fc715a706cb86a
Grabbing search results from lore.kernel.org
WARNING: duplicate messages found at index 1
Subject 1: Forwarded: [PATCH v3] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
Subject 2: Forwarded: [PATCH v4] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
Subject 1: Forwarded: [PATCH v2] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
Subject 2: Forwarded: [PATCH v3] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
Subject 1: Forwarded: [PATCH] ext4: validate extent entries before caching in ext4_find_extent()
Subject 2: Forwarded: [PATCH v2] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
Subject 1: Forwarded: [PATCH] ext4: validate extent entries before caching in ext4_find_extent()
Subject 2: Forwarded: [PATCH] ext4: validate extent entries before caching in ext4_find_extent()
2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
Subject 1: Forwarded: [PATCH] ext4: fix BUG_ON in ext4_es_cache_extent due to out-of-order extents
Subject 2: Forwarded: [PATCH] ext4: validate extent entries before caching in ext4_find_extent()
2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
Subject 1: Forwarded: [PATCH] ext4: fix BUG_ON in ext4_es_cache_extent due to out-of-order extents
Subject 2: Forwarded: [PATCH] ext4: fix BUG_ON in ext4_es_cache_extent due to out-of-order extents
2 is not a reply... assume additional patch
WARNING: duplicate messages found at index 1
Subject 1: Forwarded: [PATCH] ext4: Fix extent boundary validation in extent tree
Subject 2: Forwarded: [PATCH] ext4: fix BUG_ON in ext4_es_cache_extent due to out-of-order extents
2 is not a reply... assume additional patch
Found matching series by patch-id
---
This patch is present in the following series:
---
v1: Forwarded: [PATCH] ext4: Fix extent boundary validation in extent tree
https://lore.kernel.org/r/68d8e78f.050a0220.25d7ab.04c8.GAE@google.com
v4: [PATCH v4] ext4: detect invalid INLINE_DATA + EXTENTS flag combination
https://lore.kernel.org/r/20250930112810.315095-1-kartikey406@gmail.com
If you look at the first Lore URL, it is absolutely NOT CORRECT. This
isn't purely b4's fault. the problem is we have some developers who
are blindly sending random patches bashing at the code to see if they
can make syzbot stop complaining. But it results in a fairly
confusing patch history.
I can also imagine some UI polish; for excample, a bunch of *how* b4
dig tried to find thigns should probably only show up with a -v
verbose option.
And when displaying thje results, it would be useful if it (a) printed
the date (and how it relates to the commit date), and (b) flag whether
the patch-id is an exact match, or whether it isn't with perhaps some
kind of diference score, so the human being knows whether they need to
take a closer look.
- Ted
P.S. "Mindless" is also a way of saying, "decreasing the load on
overloaded maintainers". Something like a mindless inclusion of a
Message-ID tag would add an extra 60-80 characters of overhead into
the commit trailer; I can understand why Linus might not like it, but
from the perspectve of saving time from maintainers, I'm going to be
selfish enough to want something that saves me time.
If "b4 dig" can be made good enough that 99% of the time, it works
just as well as mnually inserted metadata, great! It's just that "b4
dig" is still a little rough around the edges, and I suspect many
people haven't tried using it yet. Hence the interest in other
alternatives...
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 17:00 ` Linus Torvalds
2025-10-13 18:14 ` Paolo Bonzini
2025-10-13 21:59 ` Theodore Ts'o
@ 2025-10-13 23:09 ` Michael S. Tsirkin
2025-10-14 1:23 ` Linus Torvalds
2025-10-15 7:33 ` Geert Uytterhoeven
3 siblings, 1 reply; 81+ messages in thread
From: Michael S. Tsirkin @ 2025-10-13 23:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paolo Bonzini, Konstantin Ryabitsev, users, tools
Thanks Linus!
One note:
On Mon, Oct 13, 2025 at 10:00:01AM -0700, Linus Torvalds wrote:
...
> Because we *HAVE* automated information that is already sufficient.
> Every single commit already fundamentally has sufficient information
> to find the submission if it was to a lore-tracked mailing list:
>
> - patch ID
>
> - commit date
>
> - subject line and patch date (note: maybe from the email, maybe in
> the body of the email)
>
> - author name and email (note again: might be the email 'from', but
> might well be the 'body of the email' From: line)
Well I for one would often ask the contributor to repost
modifying just the commit message.
The only thing distinguishing posts then is the date?
Doesn't it seem somewhat fragile, to rely on date?
E.g. thinkably someone can post an old version of my patch (e.g. include
in their patchset) and at the same time I happen to
post one with an updated commit log.
Now what?
As a maintainer, I also sometimes squash two patches together, what then?
--
MST
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 23:09 ` Michael S. Tsirkin
@ 2025-10-14 1:23 ` Linus Torvalds
2025-10-14 10:38 ` Michael S. Tsirkin
0 siblings, 1 reply; 81+ messages in thread
From: Linus Torvalds @ 2025-10-14 1:23 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Paolo Bonzini, Konstantin Ryabitsev, users, tools
On Mon, 13 Oct 2025 at 16:09, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> Well I for one would often ask the contributor to repost
> modifying just the commit message.
>
> The only thing distinguishing posts then is the date?
> Doesn't it seem somewhat fragile, to rely on date?
I wouldn't rely on date. That's the point. None of those emails are
any special. Not the one that was applied, for one. Because if there
are multipel; versions, the commentary on the *earlier* ones are
likely as relevant - or *more* relevant - than the one that was
applied.
The primary thing is the patch ID.
And if you change the patch as you apply it, at that point *you*
should point that out. And at that point, by all means say "original
at XYZ, I changed it to do ABC".
See? It's not that "Link" lines are bad. What is bad is *pointless*
link lines that had no thought, were added by automation, and don't
add any actual information.
Linus
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-14 1:23 ` Linus Torvalds
@ 2025-10-14 10:38 ` Michael S. Tsirkin
2025-10-14 16:56 ` Linus Torvalds
0 siblings, 1 reply; 81+ messages in thread
From: Michael S. Tsirkin @ 2025-10-14 10:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paolo Bonzini, Konstantin Ryabitsev, users, tools
On Mon, Oct 13, 2025 at 06:23:49PM -0700, Linus Torvalds wrote:
> On Mon, 13 Oct 2025 at 16:09, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > Well I for one would often ask the contributor to repost
> > modifying just the commit message.
> >
> > The only thing distinguishing posts then is the date?
> > Doesn't it seem somewhat fragile, to rely on date?
>
> I wouldn't rely on date. That's the point. None of those emails are
> any special. Not the one that was applied, for one. Because if there
> are multipel; versions, the commentary on the *earlier* ones are
> likely as relevant - or *more* relevant - than the one that was
> applied.
>
> The primary thing is the patch ID.
Hmm. Sorry that I'm being dense. But nowdays, e.g. the Fixes tag carries
*a lot* of weight, given how automation trusts it to know
where to backport the patch. And the description is critical because
stable maintainers trust it to make decisions on whether to backport
in the 1st place.
So let's say I have v2 applied and v1 had a different commit log but
same patch ID. A contributor (or myself, if I forgot!) is wondering
whether I applied v2 or v1 with respect to v4 having the correct
commit log and v2 having a wrong one.
What do you suggest then, if not reading all of commit log
and also not looking at the date?
> And if you change the patch as you apply it, at that point *you*
> should point that out. And at that point, by all means say "original
> at XYZ, I changed it to do ABC".
>
> See? It's not that "Link" lines are bad. What is bad is *pointless*
> link lines that had no thought, were added by automation, and don't
> add any actual information.
>
> Linus
That part's clear.
--
MST
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-14 10:38 ` Michael S. Tsirkin
@ 2025-10-14 16:56 ` Linus Torvalds
2025-10-14 18:05 ` Luck, Tony
0 siblings, 1 reply; 81+ messages in thread
From: Linus Torvalds @ 2025-10-14 16:56 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Paolo Bonzini, Konstantin Ryabitsev, users, tools
On Tue, 14 Oct 2025 at 03:38, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> What do you suggest then, if not reading all of commit log
> and also not looking at the date?
I think we're talking past each other.
I'm not saying that you shouldn't look at other things. I'm saying
that the patch being identical is the *primary* thing, and that
earlier submissions of the same patch are very much relevant.
So if you start filtering by the author date of a commit - even if
that does find you an exact match - I think you're filtering way too
much (at least by default).
Now, using some kind of fairly simple scoring algorithm that gives
higher relevance for things that match might be the best of all
worlds: show other matches for the patch, but maybe rank it higher
when it matches "better" (which would include things like the author
date matching the date of the email - always with the caveat that the
"Date:" might be either the one from the email headers, or from the
top of the body of the email).
But people who use non-git patch maintenance systems will often mess
up the author date completely, which is why I'd not want to make it
very important. Maybe that's non-git use is getting to be uncommon
these days (or maybe other patch management systems have just gotten
better at tracking dates).
The one date I think is worth actually special is the commit date -
and not as an exact match, but as a cut-off.
Not because that date is inherently very important, but simply because
assuming clocks aren't too much out of phase (and assuming people
don't play games), the commit date can be used as a cut-off for
causality. Emails that happened after that date are obviously not the
*cause* of the commit, and are more likely to be the effect (with
back-ports being one big case).
Linus
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-14 16:56 ` Linus Torvalds
@ 2025-10-14 18:05 ` Luck, Tony
2025-10-14 18:41 ` Linus Torvalds
0 siblings, 1 reply; 81+ messages in thread
From: Luck, Tony @ 2025-10-14 18:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael S. Tsirkin, Paolo Bonzini, Konstantin Ryabitsev, users,
tools
On Tue, Oct 14, 2025 at 09:56:02AM -0700, Linus Torvalds wrote:
> On Tue, 14 Oct 2025 at 03:38, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > What do you suggest then, if not reading all of commit log
> > and also not looking at the date?
>
> I think we're talking past each other.
>
> I'm not saying that you shouldn't look at other things. I'm saying
> that the patch being identical is the *primary* thing, and that
> earlier submissions of the same patch are very much relevant.
While there may be many archived e-mails with the same patch-id, the one
that was actually applied is "special", *if it is part of a series*.
An automatically applied Message-ID (whether a clickable link, or just a
raw message ID) gives a pointer to the specific e-mail. That contains an
In-Reply-To pointing to the cover letter.
So this 0005/0045 patch might be the same is six different versions of the
series. The other patches likely changed (hence new version).
Anyone looking to backport this patch won't care about the identical copy
in v2, v3, v4. They need the specific one that was applied to get the
surrounding context.
Someone who bisected a bug to this commit, can reply to the specific
e-mail that was applied (thus getting everyone involved in the original
submission into the e-mail thread).
-Tony
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-14 18:05 ` Luck, Tony
@ 2025-10-14 18:41 ` Linus Torvalds
2025-10-14 19:09 ` Paolo Bonzini
` (2 more replies)
0 siblings, 3 replies; 81+ messages in thread
From: Linus Torvalds @ 2025-10-14 18:41 UTC (permalink / raw)
To: Luck, Tony
Cc: Michael S. Tsirkin, Paolo Bonzini, Konstantin Ryabitsev, users,
tools
On Tue, 14 Oct 2025 at 11:05, Luck, Tony <tony.luck@intel.com> wrote:
>
> While there may be many archived e-mails with the same patch-id, the one
> that was actually applied is "special", *if it is part of a series*.
No.
You are arguing as if this was a "one or the other" thing. And it really isn't.
With the link you only get *ONE* submission.
With "b4 dig", you get *ALL* of them. It's not like you lost the one
that was applied, you get more information.
And I'm arguing that if there were multiple submissions, those earlier
submissions are relevant and interesting and often have *MORE* email
replies associated with them than the final one.
IOW, your argument seems to be "the applied one is special, so it's
the *only* one you should see".
And I'm claiming that's a completely bogus argument exactly because it
claims that the one that got applied is *so* special that the others
don't matter at all.
That's BS.
Because the older copies - and the series they were attached to - are
still very relevant. The discussion that caused a v5 to become a v6
is not irrelevant just because v6 was the one that was applied.
In fact, it might be very relevant indeed if it turns out that v6 was
buggy, wouldn't you say?
This is why I think all the arguments for "the applied series is
special" is so utterly pointless pure sh*t. You are literally arguing
as if some "b4 dig" wouldn't find that last version *too*, and as if
older versions suddenly became irrelevant.
It's intellectually completely dishonest and pointless to claim that
early versions aren't relevant.
Linus
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-14 18:41 ` Linus Torvalds
@ 2025-10-14 19:09 ` Paolo Bonzini
2025-10-14 21:10 ` Jason Gunthorpe
2025-10-15 7:37 ` Geert Uytterhoeven
2 siblings, 0 replies; 81+ messages in thread
From: Paolo Bonzini @ 2025-10-14 19:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Luck, Tony, Michael S. Tsirkin, Konstantin Ryabitsev, users,
tools
Il mar 14 ott 2025, 20:41 Linus Torvalds
<torvalds@linuxfoundation.org> ha scritto:
>
> On Tue, 14 Oct 2025 at 11:05, Luck, Tony <tony.luck@intel.com> wrote:
> >
> > While there may be many archived e-mails with the same patch-id, the one
> > that was actually applied is "special", *if it is part of a series*.
>
> No.
>
> You are arguing as if this was a "one or the other" thing. And it really isn't.
>
> With the link you only get *ONE* submission.
>
> With "b4 dig", you get *ALL* of them. It's not like you lost the one
> that was applied, you get more information.
And no one is disputing that.
The point is that there are multiple reasons to "interact" with a
committed patch via email, but for the vast majority of cases, people
only need the exact version that was committed.
If I see an oops in an unrelated subsystem, I will gladly spend some
time with "git log -p" and find a patch to reply to, but after that
it's honestly not my business to investigate further, look at past
versions and all that, unless asked by the maintainer. The maintainer
will use "b4 dig", I won't.
Moving up the maintenance hierarchy, less and less code becomes
Someone Else's Problem, and that's why you are quite literally
special. If you end up looking at a patch that was submitted and the
history behind it, there's a much higher chance that you'll go past
the simple case.
You're focusing on the 1% case and discounting the 99% case, just
because (for good reasons) you see reversed percentages. There's also
the fact that "b4 dig" could start digging from the message id (like
patchew does), but that's secondary.
Paolo
>
> And I'm arguing that if there were multiple submissions, those earlier
> submissions are relevant and interesting and often have *MORE* email
> replies associated with them than the final one.
>
> IOW, your argument seems to be "the applied one is special, so it's
> the *only* one you should see".
>
> And I'm claiming that's a completely bogus argument exactly because it
> claims that the one that got applied is *so* special that the others
> don't matter at all.
>
> That's BS.
>
> Because the older copies - and the series they were attached to - are
> still very relevant. The discussion that caused a v5 to become a v6
> is not irrelevant just because v6 was the one that was applied.
>
> In fact, it might be very relevant indeed if it turns out that v6 was
> buggy, wouldn't you say?
>
> This is why I think all the arguments for "the applied series is
> special" is so utterly pointless pure sh*t. You are literally arguing
> as if some "b4 dig" wouldn't find that last version *too*, and as if
> older versions suddenly became irrelevant.
>
> It's intellectually completely dishonest and pointless to claim that
> early versions aren't relevant.
>
> Linus
>
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-14 18:41 ` Linus Torvalds
2025-10-14 19:09 ` Paolo Bonzini
@ 2025-10-14 21:10 ` Jason Gunthorpe
2025-10-15 7:37 ` Geert Uytterhoeven
2 siblings, 0 replies; 81+ messages in thread
From: Jason Gunthorpe @ 2025-10-14 21:10 UTC (permalink / raw)
To: Linus Torvalds
Cc: Luck, Tony, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
On Tue, Oct 14, 2025 at 11:41:08AM -0700, Linus Torvalds wrote:
> And I'm arguing that if there were multiple submissions, those earlier
> submissions are relevant and interesting and often have *MORE* email
> replies associated with them than the final one.
Yes, and for this reason I always link back to the prior versions from
the cover letter of the latest.
This way you can go from the Link: header, into Lore, click to the
cover letter see the change log and then click through all the other
versions of the series without having to rely on any heuristics or
special tools.
I know many others do the same but we don't have a best practices
document to say to do this.
Jason
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-14 18:41 ` Linus Torvalds
2025-10-14 19:09 ` Paolo Bonzini
2025-10-14 21:10 ` Jason Gunthorpe
@ 2025-10-15 7:37 ` Geert Uytterhoeven
2 siblings, 0 replies; 81+ messages in thread
From: Geert Uytterhoeven @ 2025-10-15 7:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Luck, Tony, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
Hi Linus,
On Tue, 14 Oct 2025 at 21:21, Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
> On Tue, 14 Oct 2025 at 11:05, Luck, Tony <tony.luck@intel.com> wrote:
> > While there may be many archived e-mails with the same patch-id, the one
> > that was actually applied is "special", *if it is part of a series*.
>
> No.
>
> You are arguing as if this was a "one or the other" thing. And it really isn't.
>
> With the link you only get *ONE* submission.
>
> With "b4 dig", you get *ALL* of them. It's not like you lost the one
> that was applied, you get more information.
>
> And I'm arguing that if there were multiple submissions, those earlier
> submissions are relevant and interesting and often have *MORE* email
> replies associated with them than the final one.
More is not always better. It depends on what you are looking for.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-13 17:00 ` Linus Torvalds
` (2 preceding siblings ...)
2025-10-13 23:09 ` Michael S. Tsirkin
@ 2025-10-15 7:33 ` Geert Uytterhoeven
2025-10-15 9:38 ` Miguel Ojeda
2025-10-15 13:51 ` Martin K. Petersen
3 siblings, 2 replies; 81+ messages in thread
From: Geert Uytterhoeven @ 2025-10-15 7:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael S. Tsirkin, Paolo Bonzini, Konstantin Ryabitsev, users,
tools
Hi Linus,
On Mon, 13 Oct 2025 at 19:16, Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
> I object *strongly* to any random noise that doesn't add explicit
> value. For example, the argument that "I want to see which of the
> identical 17 submissions was used" I find completely pointless.
That is your prerogative, but I find it extremely useful. Not just for
reporting bugs, but also for queuing patches (has anyone reported a bug
between me taking the patch, and actually queuing it?).
Other people have other use cases.
> If you can already look things up by patch ID - and you can - then why
> is it AT ALL relevant "which of the six identical patch submissions
> was taken". They were the same patch.
So which version do you reply to when submitting a bug report? If you
find an issue, and want to submit a bug report, which older versions of
the same patch do you have to scan for replies to discover if someone
already ran into the same issue?
An https://patch.msgid.link/-Link serves (a.o.) as a pointer to where
to report an issue, and where to find other reported issues. You can
consider it a pre-assigned bug report ticket.
Note that I am also replying to your email in this thread, and not just
starting a new conversation, with a different set of addresses in CC.
> And that's really my objection here. The thing I really really hate
> about how people used "Link:" patches was that it was both mindless
> and pointless.
FTR, I dislike the use of Cc: in patch bodies.
> I have no objections to *mindful* use of Link patches.
>
> The workflow that Steven Rostedt explains with multiple versions that
> are explicitly linked together is fine: if you have real mindful use
> of a "Link", then go on using it, IF YOU THINK ABOUT IT, and didn't
> just mindlessly automate it.
I'd love for more people to link to the previous version when submitting
a new one (for substantial work, not for simple and obvious changes).
It helps a lot when trying to find out why something was changed
between e.g. vN-4 and VN-3 (that is: when I am looking for that
info, and don't just want to find out the actual version that made
it upstream).
> Because we *HAVE* automated information that is already sufficient.
> Every single commit already fundamentally has sufficient information
> to find the submission if it was to a lore-tracked mailing list:
>
> - patch ID
Patch ID is not sufficient, because maintainers change patches
regularly, for minor improvements, or because of small conflicts.
> - commit date
It is not uncommon that a different version than the last one that was
posted is applied: the last version may introduce a bug, the developer
keeps on submitting newer versions after the maintainer already applied
it, the maintainer accidentally took the wrong version, ...
> - subject line and patch date (note: maybe from the email, maybe in
> the body of the email)
These may be edited by the maintainer, too, because of prefixes that do
not match the subsystem style, or because of spelling/grammar/wording
issues.
> I argue that "Link" makes everything worse. It does not add
> information. It adds redundant data (explicit difference between
> "information" and "data"), and not in a good way.
Also, think database normalization
> What's the real argument against "b4 dig"?
It's one more indirection, and can never be 100% correct, compared
to using the Message-ID in the original patch.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 7:33 ` Geert Uytterhoeven
@ 2025-10-15 9:38 ` Miguel Ojeda
2025-10-15 12:11 ` Mark Brown
2025-10-15 14:50 ` [workflows]Re: " Steven Rostedt
2025-10-15 13:51 ` Martin K. Petersen
1 sibling, 2 replies; 81+ messages in thread
From: Miguel Ojeda @ 2025-10-15 9:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
On Wed, Oct 15, 2025 at 9:37 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> FTR, I dislike the use of Cc: in patch bodies.
Yeah, when they are added automatically as a big block (e.g. 10
lines), it is not great.
Personally, I use Cc: when I think someone should be explicitly pinged
for a reason. That is, people that may want to provide comment but
that wouldn't be Cc'd otherwise from `MAINTAINERS`, e.g. typically
from external projects.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 9:38 ` Miguel Ojeda
@ 2025-10-15 12:11 ` Mark Brown
2025-10-15 13:50 ` James Bottomley
2025-10-15 14:37 ` Miguel Ojeda
2025-10-15 14:50 ` [workflows]Re: " Steven Rostedt
1 sibling, 2 replies; 81+ messages in thread
From: Mark Brown @ 2025-10-15 12:11 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Geert Uytterhoeven, Linus Torvalds, Michael S. Tsirkin,
Paolo Bonzini, Konstantin Ryabitsev, users, tools
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
On Wed, Oct 15, 2025 at 11:38:41AM +0200, Miguel Ojeda wrote:
> On Wed, Oct 15, 2025 at 9:37 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > FTR, I dislike the use of Cc: in patch bodies.
> Yeah, when they are added automatically as a big block (e.g. 10
> lines), it is not great.
> Personally, I use Cc: when I think someone should be explicitly pinged
> for a reason. That is, people that may want to provide comment but
> that wouldn't be Cc'd otherwise from `MAINTAINERS`, e.g. typically
> from external projects.
Ccing people makes sense but doesn't need something in the patch body,
and especially doesn't need to end up in the commit log.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 12:11 ` Mark Brown
@ 2025-10-15 13:50 ` James Bottomley
2025-10-15 13:59 ` Jürgen Groß
` (2 more replies)
2025-10-15 14:37 ` Miguel Ojeda
1 sibling, 3 replies; 81+ messages in thread
From: James Bottomley @ 2025-10-15 13:50 UTC (permalink / raw)
To: Mark Brown, Miguel Ojeda
Cc: Geert Uytterhoeven, Linus Torvalds, Michael S. Tsirkin,
Paolo Bonzini, Konstantin Ryabitsev, users, tools
[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
On Wed, 2025-10-15 at 13:11 +0100, Mark Brown wrote:
> On Wed, Oct 15, 2025 at 11:38:41AM +0200, Miguel Ojeda wrote:
> > On Wed, Oct 15, 2025 at 9:37 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
>
> > > FTR, I dislike the use of Cc: in patch bodies.
>
> > Yeah, when they are added automatically as a big block (e.g. 10
> > lines), it is not great.
>
> > Personally, I use Cc: when I think someone should be explicitly
> > pinged for a reason. That is, people that may want to provide
> > comment but that wouldn't be Cc'd otherwise from `MAINTAINERS`,
> > e.g. typically from external projects.
>
> Ccing people makes sense but doesn't need something in the patch
> body, and especially doesn't need to end up in the commit log.
Absolutely. But part of the problem is people who Cc different parts
of their patch set to different people don't want to use the --cc
global of git-send-email, so they tend to put it in the commit log.
What would be nice would be if git-send-email had an option to strip cc
lines when its sending the patch. You can actually sort of do this
manually if you add a `---' and put the Cc: trailers below it (I
actually use this for preserving the version log as well) because am
import discards anything below `---'.
It is also definitely possible to add a git commit hook to strip cc's
when doing am.
Regards,
James
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 13:50 ` James Bottomley
@ 2025-10-15 13:59 ` Jürgen Groß
2025-10-15 15:08 ` Mark Brown
2025-10-15 15:14 ` Peter Zijlstra
2 siblings, 0 replies; 81+ messages in thread
From: Jürgen Groß @ 2025-10-15 13:59 UTC (permalink / raw)
To: James Bottomley, Mark Brown, Miguel Ojeda
Cc: Geert Uytterhoeven, Linus Torvalds, Michael S. Tsirkin,
Paolo Bonzini, Konstantin Ryabitsev, users, tools
[-- Attachment #1.1.1: Type: text/plain, Size: 2008 bytes --]
On 15.10.25 15:50, James Bottomley wrote:
> On Wed, 2025-10-15 at 13:11 +0100, Mark Brown wrote:
>> On Wed, Oct 15, 2025 at 11:38:41AM +0200, Miguel Ojeda wrote:
>>> On Wed, Oct 15, 2025 at 9:37 AM Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>
>>>> FTR, I dislike the use of Cc: in patch bodies.
>>
>>> Yeah, when they are added automatically as a big block (e.g. 10
>>> lines), it is not great.
>>
>>> Personally, I use Cc: when I think someone should be explicitly
>>> pinged for a reason. That is, people that may want to provide
>>> comment but that wouldn't be Cc'd otherwise from `MAINTAINERS`,
>>> e.g. typically from external projects.
>>
>> Ccing people makes sense but doesn't need something in the patch
>> body, and especially doesn't need to end up in the commit log.
>
> Absolutely. But part of the problem is people who Cc different parts
> of their patch set to different people don't want to use the --cc
> global of git-send-email, so they tend to put it in the commit log.
> What would be nice would be if git-send-email had an option to strip cc
> lines when its sending the patch. You can actually sort of do this
> manually if you add a `---' and put the Cc: trailers below it (I
> actually use this for preserving the version log as well) because am
> import discards anything below `---'.
>
> It is also definitely possible to add a git commit hook to strip cc's
> when doing am.
I'm using basically an add_maintainers script from the Xen project [1].
It is adding the maintainers for each patch of a series individually,
based on the MAINTAINERS file and the files the patch is touching.
The cover letter will have a logical OR of the Cc: of all patches.
The Cc: additions will be in the header part of the patch, so they don't
show up in the commit message.
[1]:
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=scripts/add_maintainers.pl;h=5ad08697303f2aa59248116f0bea92e487368a9a;hb=refs/heads/staging
Juergen
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 13:50 ` James Bottomley
2025-10-15 13:59 ` Jürgen Groß
@ 2025-10-15 15:08 ` Mark Brown
2025-10-15 15:14 ` Peter Zijlstra
2 siblings, 0 replies; 81+ messages in thread
From: Mark Brown @ 2025-10-15 15:08 UTC (permalink / raw)
To: James Bottomley
Cc: Miguel Ojeda, Geert Uytterhoeven, Linus Torvalds,
Michael S. Tsirkin, Paolo Bonzini, Konstantin Ryabitsev, users,
tools
[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]
On Wed, Oct 15, 2025 at 09:50:48AM -0400, James Bottomley wrote:
> On Wed, 2025-10-15 at 13:11 +0100, Mark Brown wrote:
> > Ccing people makes sense but doesn't need something in the patch
> > body, and especially doesn't need to end up in the commit log.
> Absolutely. But part of the problem is people who Cc different parts
> of their patch set to different people don't want to use the --cc
> global of git-send-email, so they tend to put it in the commit log.
Sure, I understand what people are trying to do.
> What would be nice would be if git-send-email had an option to strip cc
> lines when its sending the patch. You can actually sort of do this
> manually if you add a `---' and put the Cc: trailers below it (I
> actually use this for preserving the version log as well) because am
> import discards anything below `---'.
That's what I do if I want to include per patch Ccs, just put them with
the per-patch changelog.
> It is also definitely possible to add a git commit hook to strip cc's
> when doing am.
But not stable ones which we do actually want!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 13:50 ` James Bottomley
2025-10-15 13:59 ` Jürgen Groß
2025-10-15 15:08 ` Mark Brown
@ 2025-10-15 15:14 ` Peter Zijlstra
2025-10-15 15:18 ` [workflows]Re: " Steven Rostedt
2 siblings, 1 reply; 81+ messages in thread
From: Peter Zijlstra @ 2025-10-15 15:14 UTC (permalink / raw)
To: James Bottomley
Cc: Mark Brown, Miguel Ojeda, Geert Uytterhoeven, Linus Torvalds,
Michael S. Tsirkin, Paolo Bonzini, Konstantin Ryabitsev, users,
tools
On Wed, Oct 15, 2025 at 09:50:48AM -0400, James Bottomley wrote:
> Absolutely. But part of the problem is people who Cc different parts
> of their patch set to different people don't want to use the --cc
> global of git-send-email,
I so wish people would stop doing that. There is nothing more annoying
than getting a partial series.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 15:14 ` Peter Zijlstra
@ 2025-10-15 15:18 ` Steven Rostedt
2025-10-15 15:53 ` Peter Zijlstra
0 siblings, 1 reply; 81+ messages in thread
From: Steven Rostedt @ 2025-10-15 15:18 UTC (permalink / raw)
To: Peter Zijlstra
Cc: James Bottomley, Mark Brown, Miguel Ojeda, Geert Uytterhoeven,
Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
On Wed, 15 Oct 2025 17:14:47 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Oct 15, 2025 at 09:50:48AM -0400, James Bottomley wrote:
>
> > Absolutely. But part of the problem is people who Cc different parts
> > of their patch set to different people don't want to use the --cc
> > global of git-send-email,
>
> I so wish people would stop doing that. There is nothing more annoying
> than getting a partial series.
I disagree. I much rather get a partial series where I'm only Cc'd on the
patches that I need to look at. If I get Cc'd on 20 patches where there's
one or two patches that affects my code, I will most likely ignore the entire
thing.
We have lore and b4 today. If you want to see the entire series, simply use
that.
-- Steve
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 15:18 ` [workflows]Re: " Steven Rostedt
@ 2025-10-15 15:53 ` Peter Zijlstra
2025-10-15 15:59 ` Steven Rostedt
0 siblings, 1 reply; 81+ messages in thread
From: Peter Zijlstra @ 2025-10-15 15:53 UTC (permalink / raw)
To: Steven Rostedt
Cc: James Bottomley, Mark Brown, Miguel Ojeda, Geert Uytterhoeven,
Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
On Wed, Oct 15, 2025 at 11:18:16AM -0400, Steven Rostedt wrote:
> On Wed, 15 Oct 2025 17:14:47 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > On Wed, Oct 15, 2025 at 09:50:48AM -0400, James Bottomley wrote:
> >
> > > Absolutely. But part of the problem is people who Cc different parts
> > > of their patch set to different people don't want to use the --cc
> > > global of git-send-email,
> >
> > I so wish people would stop doing that. There is nothing more annoying
> > than getting a partial series.
>
> I disagree. I much rather get a partial series where I'm only Cc'd on the
> patches that I need to look at. If I get Cc'd on 20 patches where there's
> one or two patches that affects my code, I will most likely ignore the entire
> thing.
>
> We have lore and b4 today. If you want to see the entire series, simply use
> that.
I have sufficient pending email such that any extra effort just means I
won't bother.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 15:53 ` Peter Zijlstra
@ 2025-10-15 15:59 ` Steven Rostedt
2025-10-15 16:06 ` Peter Zijlstra
0 siblings, 1 reply; 81+ messages in thread
From: Steven Rostedt @ 2025-10-15 15:59 UTC (permalink / raw)
To: Peter Zijlstra
Cc: James Bottomley, Mark Brown, Miguel Ojeda, Geert Uytterhoeven,
Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
On Wed, 15 Oct 2025 17:53:46 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> I have sufficient pending email such that any extra effort just means I
> won't bother.
I'm curious. Why do you need to see the entire series? Would a cover letter
and the patches that affect your code be enough?
Because seriously, I've skipped several series because I look at one or two
patches and say to myself "why am I Cc'd on this?" and skip it. Only later
to find out that patch 18 affected by code.
It's much easier to find the entire series from a single patch than it is
to find "what touches my code" from a large series.
-- Steve
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 15:59 ` Steven Rostedt
@ 2025-10-15 16:06 ` Peter Zijlstra
2025-10-15 16:15 ` Steven Rostedt
` (2 more replies)
0 siblings, 3 replies; 81+ messages in thread
From: Peter Zijlstra @ 2025-10-15 16:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: James Bottomley, Mark Brown, Miguel Ojeda, Geert Uytterhoeven,
Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
On Wed, Oct 15, 2025 at 11:59:17AM -0400, Steven Rostedt wrote:
> On Wed, 15 Oct 2025 17:53:46 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > I have sufficient pending email such that any extra effort just means I
> > won't bother.
>
> I'm curious. Why do you need to see the entire series? Would a cover letter
> and the patches that affect your code be enough?
>
> Because seriously, I've skipped several series because I look at one or two
> patches and say to myself "why am I Cc'd on this?" and skip it. Only later
> to find out that patch 18 affected by code.
>
> It's much easier to find the entire series from a single patch than it is
> to find "what touches my code" from a large series.
Because when I see a single patch, I end up wondering WTF does it do
this, and then I have to go find the others, which I don't have, I get
grumpy and either NAK or just yell. And no, the cover letter rarely
answers the questions I have.
Finding where or which patch is directly affecting 'your' code is mostly
trivially done by scanning the diffstats.
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 16:06 ` Peter Zijlstra
@ 2025-10-15 16:15 ` Steven Rostedt
2025-10-15 16:43 ` Mark Brown
2025-10-15 16:15 ` Vlastimil Babka (SUSE)
2025-10-15 18:40 ` Laurent Pinchart
2 siblings, 1 reply; 81+ messages in thread
From: Steven Rostedt @ 2025-10-15 16:15 UTC (permalink / raw)
To: Peter Zijlstra
Cc: James Bottomley, Mark Brown, Miguel Ojeda, Geert Uytterhoeven,
Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
On Wed, 15 Oct 2025 18:06:22 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> Finding where or which patch is directly affecting 'your' code is mostly
> trivially done by scanning the diffstats.
I don't have the time to scan 20 different diffstats that are at the end of
every change log. Especially when it's not in the immediate view, and
requires scrolling. It takes much more time than a simple lore lookup.
And sometimes, the files don't actually tell me if I should look at a patch
or not. If there's a patch I need to look at, just Cc me on that patch. I
usually don't care about the rest.
-- Steve
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 16:15 ` Steven Rostedt
@ 2025-10-15 16:43 ` Mark Brown
0 siblings, 0 replies; 81+ messages in thread
From: Mark Brown @ 2025-10-15 16:43 UTC (permalink / raw)
To: Steven Rostedt
Cc: Peter Zijlstra, James Bottomley, Miguel Ojeda, Geert Uytterhoeven,
Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
On Wed, Oct 15, 2025 at 12:15:02PM -0400, Steven Rostedt wrote:
> Peter Zijlstra <peterz@infradead.org> wrote:
> > Finding where or which patch is directly affecting 'your' code is mostly
> > trivially done by scanning the diffstats.
> I don't have the time to scan 20 different diffstats that are at the end of
> every change log. Especially when it's not in the immediate view, and
> requires scrolling. It takes much more time than a simple lore lookup.
> And sometimes, the files don't actually tell me if I should look at a patch
> or not. If there's a patch I need to look at, just Cc me on that patch. I
> usually don't care about the rest.
The trick is often that without at least the cover letter it can be hard
to tell if the series needs to go in together, if each subsystem should
pick the patches relevant to them or whatever. Some context does help
with triage, though at least for me often just the cover letter and any
shared patches are fine.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 16:06 ` Peter Zijlstra
2025-10-15 16:15 ` Steven Rostedt
@ 2025-10-15 16:15 ` Vlastimil Babka (SUSE)
2025-10-15 16:44 ` Steven Rostedt
2025-10-15 18:40 ` Laurent Pinchart
2 siblings, 1 reply; 81+ messages in thread
From: Vlastimil Babka (SUSE) @ 2025-10-15 16:15 UTC (permalink / raw)
To: Peter Zijlstra, Steven Rostedt
Cc: James Bottomley, Mark Brown, Miguel Ojeda, Geert Uytterhoeven,
Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
On 10/15/25 18:06, Peter Zijlstra wrote:
> On Wed, Oct 15, 2025 at 11:59:17AM -0400, Steven Rostedt wrote:
>> On Wed, 15 Oct 2025 17:53:46 +0200
>> Peter Zijlstra <peterz@infradead.org> wrote:
>>
>> > I have sufficient pending email such that any extra effort just means I
>> > won't bother.
>>
>> I'm curious. Why do you need to see the entire series? Would a cover letter
>> and the patches that affect your code be enough?
>>
>> Because seriously, I've skipped several series because I look at one or two
>> patches and say to myself "why am I Cc'd on this?" and skip it. Only later
>> to find out that patch 18 affected by code.
>>
>> It's much easier to find the entire series from a single patch than it is
>> to find "what touches my code" from a large series.
>
> Because when I see a single patch, I end up wondering WTF does it do
> this, and then I have to go find the others, which I don't have, I get
> grumpy and either NAK or just yell. And no, the cover letter rarely
> answers the questions I have.
>
> Finding where or which patch is directly affecting 'your' code is mostly
> trivially done by scanning the diffstats.
Such personal preferences could be encoded in MAINTAINERS with tooling doing
the right thing, perhaps.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 16:15 ` Vlastimil Babka (SUSE)
@ 2025-10-15 16:44 ` Steven Rostedt
2025-10-15 16:58 ` Konstantin Ryabitsev
2025-10-15 17:01 ` Miguel Ojeda
0 siblings, 2 replies; 81+ messages in thread
From: Steven Rostedt @ 2025-10-15 16:44 UTC (permalink / raw)
To: Vlastimil Babka (SUSE)
Cc: Peter Zijlstra, James Bottomley, Mark Brown, Miguel Ojeda,
Geert Uytterhoeven, Linus Torvalds, Michael S. Tsirkin,
Paolo Bonzini, Konstantin Ryabitsev, users, tools
On Wed, 15 Oct 2025 18:15:37 +0200
"Vlastimil Babka (SUSE)" <vbabka@kernel.org> wrote:
> Such personal preferences could be encoded in MAINTAINERS with tooling doing
> the right thing, perhaps.
I was just about to reply saying the same thing!
Yes, could we have a way to denote in MAINTAINERS if a maintainer wants the
entire series or not?
I see people complain about both (like Peter and I are now).
I don't want the entire series and Peter does. If we can denote a way in
maintainers and have get-maintainers have some kind of option to make a way
to send patches, this would be great!
-- Steve
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 16:44 ` Steven Rostedt
@ 2025-10-15 16:58 ` Konstantin Ryabitsev
2025-10-16 9:28 ` Matthieu Baerts
2025-10-15 17:01 ` Miguel Ojeda
1 sibling, 1 reply; 81+ messages in thread
From: Konstantin Ryabitsev @ 2025-10-15 16:58 UTC (permalink / raw)
To: Steven Rostedt
Cc: Vlastimil Babka (SUSE), Peter Zijlstra, James Bottomley,
Mark Brown, Miguel Ojeda, Geert Uytterhoeven, Linus Torvalds,
Michael S. Tsirkin, Paolo Bonzini, users, tools
On Wed, Oct 15, 2025 at 12:44:08PM -0400, Steven Rostedt wrote:
> On Wed, 15 Oct 2025 18:15:37 +0200
> "Vlastimil Babka (SUSE)" <vbabka@kernel.org> wrote:
>
> > Such personal preferences could be encoded in MAINTAINERS with tooling doing
> > the right thing, perhaps.
>
> I was just about to reply saying the same thing!
>
> Yes, could we have a way to denote in MAINTAINERS if a maintainer wants the
> entire series or not?
I can't see it working reliably:
- if there are multiple maintainers for a subsystem, how do we indicate which
one wants which preference? MAINTAINERS is a rigid non-nested flat list.
- tooling will take years to catch up to this, especially considering that
this affects *sending* tools, not retrieval tools. B4 has been able to send
series for a while, but it is only used by a fraction of contributors -- the
vast majority of patches are submitted using plain old git-send-email.
- changes to MAINTAINERS take a long time to apply globally and many people
will routinely use MAINTAINERS from an older checkout.
From my perspective, the right way to do this is to send the cover letter to
all, and then patches individually (this is how b4 does it). Fetching the rest
of the thread is trivial for me in mutt, I just have to press "4" on the
message:
macro index 4 "<pipe-message>b4 mbox -fo ~/Mail<return>"
I'm not suggesting that everyone should switch to mutt and have their messages
in local ~/Mail maildir, but I think it's an approach more likely to work than
trying to shift this to the contributor side of things.
-K
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 16:58 ` Konstantin Ryabitsev
@ 2025-10-16 9:28 ` Matthieu Baerts
0 siblings, 0 replies; 81+ messages in thread
From: Matthieu Baerts @ 2025-10-16 9:28 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Steven Rostedt, Vlastimil Babka (SUSE), Peter Zijlstra,
James Bottomley, Mark Brown, Miguel Ojeda, Geert Uytterhoeven,
Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini, users, tools,
Laurent Pinchart
Hi Konstantin,
On 15/10/2025 18:58, Konstantin Ryabitsev wrote:
> From my perspective, the right way to do this is to send the cover letter to
> all, and then patches individually (this is how b4 does it).
I might be misusing b4 (which is excellent BTW!), but I don't think
that's what it does by default when 'b4 prep --auto-to-cc' is used.
'b4 prep --auto-to-cc' will populate the cover letter with addresses
found by 'get_maintainer.pl --nogit (...)' for the whole series. Then
all these addresses will receive the cover letter and all the patches.
I agree that when addresses are manually moved from the cover-letter to
a selection of patches (in the "notes" section), they will only be used
to send the selected patches, plus the cover-letter. But that's only
when addresses are added manually or trailers collected from previous
submissions.
One last thing: even if I prefer receiving only patches modifying code
I'm maintaining (+ the cover-letter and the patches changing the API for
the context, as already mentioned by Laurent in this thread), some CIs
tracking patches sent on some specific mailing lists need the entire
series to validate these patches. But I guess no so many subsystems have
such CIs tracking patches sent on their mailing lists.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 16:44 ` Steven Rostedt
2025-10-15 16:58 ` Konstantin Ryabitsev
@ 2025-10-15 17:01 ` Miguel Ojeda
1 sibling, 0 replies; 81+ messages in thread
From: Miguel Ojeda @ 2025-10-15 17:01 UTC (permalink / raw)
To: Steven Rostedt
Cc: Vlastimil Babka (SUSE), Peter Zijlstra, James Bottomley,
Mark Brown, Geert Uytterhoeven, Linus Torvalds,
Michael S. Tsirkin, Paolo Bonzini, Konstantin Ryabitsev, users,
tools
On Wed, Oct 15, 2025 at 6:44 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Yes, could we have a way to denote in MAINTAINERS if a maintainer wants the
> entire series or not?
>
> I see people complain about both (like Peter and I are now).
>
> I don't want the entire series and Peter does. If we can denote a way in
> maintainers and have get-maintainers have some kind of option to make a way
> to send patches, this would be great!
That is the kind of thing that is meant to go into the Subsystem
Profile field (`P:`), I think.
But, of course, only some subsystems have written the document, and
even if it is there, it is unlikely that someone reads all of those
for treewide contributions (vs. contributors that often work in a
given subsystem).
So I think you would need something more targeted, ideally something
that tooling can automate.
Or, well, nowadays, with AI, I guess something like `b4` could read
those documents... :)
Cheers,
Miguel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 16:06 ` Peter Zijlstra
2025-10-15 16:15 ` Steven Rostedt
2025-10-15 16:15 ` Vlastimil Babka (SUSE)
@ 2025-10-15 18:40 ` Laurent Pinchart
2025-10-16 7:32 ` Peter Zijlstra
2 siblings, 1 reply; 81+ messages in thread
From: Laurent Pinchart @ 2025-10-15 18:40 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Steven Rostedt, James Bottomley, Mark Brown, Miguel Ojeda,
Geert Uytterhoeven, Linus Torvalds, Michael S. Tsirkin,
Paolo Bonzini, Konstantin Ryabitsev, users, tools
On Wed, Oct 15, 2025 at 06:06:22PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 15, 2025 at 11:59:17AM -0400, Steven Rostedt wrote:
> > On Wed, 15 Oct 2025 17:53:46 +0200 Peter Zijlstra wrote:
> >
> > > I have sufficient pending email such that any extra effort just means I
> > > won't bother.
> >
> > I'm curious. Why do you need to see the entire series? Would a cover letter
> > and the patches that affect your code be enough?
> >
> > Because seriously, I've skipped several series because I look at one or two
> > patches and say to myself "why am I Cc'd on this?" and skip it. Only later
> > to find out that patch 18 affected by code.
> >
> > It's much easier to find the entire series from a single patch than it is
> > to find "what touches my code" from a large series.
>
> Because when I see a single patch, I end up wondering WTF does it do
> this, and then I have to go find the others, which I don't have, I get
> grumpy and either NAK or just yell. And no, the cover letter rarely
> answers the questions I have.
>
> Finding where or which patch is directly affecting 'your' code is mostly
> trivially done by scanning the diffstats.
I've been similarly annoyed at partial series in the past, but that was
because I wasn't CC'ed on some important patches, not because I didn't
receive the whole series.
When doing tree-wide or subsystem-wide refactoring, it's typical for the
first patches to rework/improve/extend some APIs, and then for the
remaining of the series to address drivers one at a time. The cover
letter should explain the rationale. I've been CC'ed multiple times just
on a patch that touches a driver I maintain, without being CC'ed on the
first patches in the series that show what's going on. That's annoying,
even if I'm CC'ed on the cover letter. On the other hand, being CC'ed on
50 patches touching lots of drivers in very similar way causes lots of
noise.
In such cases I try to adopt a middle ground, CC'ing everybody on the
cover letter and the core patches, and CC'ing only relevant people to
the driver patches. Is this something you would find annoying, would you
prefer always being CC'ed on a full 50+ patch series ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 18:40 ` Laurent Pinchart
@ 2025-10-16 7:32 ` Peter Zijlstra
2025-10-16 8:20 ` Vlastimil Babka (SUSE)
0 siblings, 1 reply; 81+ messages in thread
From: Peter Zijlstra @ 2025-10-16 7:32 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Steven Rostedt, James Bottomley, Mark Brown, Miguel Ojeda,
Geert Uytterhoeven, Linus Torvalds, Michael S. Tsirkin,
Paolo Bonzini, Konstantin Ryabitsev, users, tools
On Wed, Oct 15, 2025 at 09:40:43PM +0300, Laurent Pinchart wrote:
> I've been similarly annoyed at partial series in the past, but that was
> because I wasn't CC'ed on some important patches, not because I didn't
> receive the whole series.
>
> When doing tree-wide or subsystem-wide refactoring, it's typical for the
> first patches to rework/improve/extend some APIs, and then for the
> remaining of the series to address drivers one at a time. The cover
> letter should explain the rationale. I've been CC'ed multiple times just
> on a patch that touches a driver I maintain, without being CC'ed on the
> first patches in the series that show what's going on. That's annoying,
> even if I'm CC'ed on the cover letter.
This, very much this. How are you supposed to judge the new API usage if
you've not seen the implementation.
But I've also had more involved cases where people were trying to solve
a 'problem' and me then only seeing a very small part of it and going
WTF. By going back and looking at the whole thing you can maybe suggest
an alternative approach, which isn't at all possible if you've just been
given a very small piece of the puzzle.
> On the other hand, being CC'ed on 50 patches touching lots of drivers
> in very similar way causes lots of noise.
>
> In such cases I try to adopt a middle ground, CC'ing everybody on the
> cover letter and the core patches, and CC'ing only relevant people to
> the driver patches. Is this something you would find annoying, would you
> prefer always being CC'ed on a full 50+ patch series ?
So I'm in the simple rules and overkill camp. Send me everything, that
way I'm sure you're not forgetting something.
The moment you start to make 'maybe' rules and people need to think
(like the Link thing seems to be now), things become subjective and
blergh.
So yeah, I would be okay with the core patches and the patches touching
'my' subsystems, but the moment we have a different view of what
constitutes that core, or someone fat-fingers it, I'd much rather have
been on everything. Everything is simpler, simple is good.
And I don't mind the 50+ patch series -- provided I can indeed really
ignore most of it. I'm very good at not reading email -- job requirement
for maintainers at this point :-(
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-16 7:32 ` Peter Zijlstra
@ 2025-10-16 8:20 ` Vlastimil Babka (SUSE)
2025-10-16 13:58 ` Steven Rostedt
0 siblings, 1 reply; 81+ messages in thread
From: Vlastimil Babka (SUSE) @ 2025-10-16 8:20 UTC (permalink / raw)
To: Peter Zijlstra, Laurent Pinchart
Cc: Steven Rostedt, James Bottomley, Mark Brown, Miguel Ojeda,
Geert Uytterhoeven, Linus Torvalds, Michael S. Tsirkin,
Paolo Bonzini, Konstantin Ryabitsev, users, tools
On 10/16/25 09:32, Peter Zijlstra wrote:
> On Wed, Oct 15, 2025 at 09:40:43PM +0300, Laurent Pinchart wrote:
>
>> I've been similarly annoyed at partial series in the past, but that was
>> because I wasn't CC'ed on some important patches, not because I didn't
>> receive the whole series.
>>
>> When doing tree-wide or subsystem-wide refactoring, it's typical for the
>> first patches to rework/improve/extend some APIs, and then for the
>> remaining of the series to address drivers one at a time. The cover
>> letter should explain the rationale. I've been CC'ed multiple times just
>> on a patch that touches a driver I maintain, without being CC'ed on the
>> first patches in the series that show what's going on. That's annoying,
>> even if I'm CC'ed on the cover letter.
>
> This, very much this. How are you supposed to judge the new API usage if
> you've not seen the implementation.
>
> But I've also had more involved cases where people were trying to solve
> a 'problem' and me then only seeing a very small part of it and going
> WTF. By going back and looking at the whole thing you can maybe suggest
> an alternative approach, which isn't at all possible if you've just been
> given a very small piece of the puzzle.
>
>> On the other hand, being CC'ed on 50 patches touching lots of drivers
>> in very similar way causes lots of noise.
>>
>> In such cases I try to adopt a middle ground, CC'ing everybody on the
>> cover letter and the core patches, and CC'ing only relevant people to
>> the driver patches. Is this something you would find annoying, would you
>> prefer always being CC'ed on a full 50+ patch series ?
>
> So I'm in the simple rules and overkill camp. Send me everything, that
> way I'm sure you're not forgetting something.
>
> The moment you start to make 'maybe' rules and people need to think
> (like the Link thing seems to be now), things become subjective and
> blergh.
Perhaps a solution that would work universally on the sender side (not
knowing particular receiver preference) and could be automated is to use
"To:" when individual patch touches the code of given maintainer, and "Cc:"
when it's not. People who only want to see their patches (plus cover letter)
like Steven would then have a hopefully easy way (easier than by diffstat)
to filter that out?
> So yeah, I would be okay with the core patches and the patches touching
> 'my' subsystems, but the moment we have a different view of what
> constitutes that core, or someone fat-fingers it, I'd much rather have
> been on everything. Everything is simpler, simple is good.
>
> And I don't mind the 50+ patch series -- provided I can indeed really
> ignore most of it. I'm very good at not reading email -- job requirement
> for maintainers at this point :-(
>
>
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-16 8:20 ` Vlastimil Babka (SUSE)
@ 2025-10-16 13:58 ` Steven Rostedt
0 siblings, 0 replies; 81+ messages in thread
From: Steven Rostedt @ 2025-10-16 13:58 UTC (permalink / raw)
To: Vlastimil Babka (SUSE)
Cc: Peter Zijlstra, Laurent Pinchart, James Bottomley, Mark Brown,
Miguel Ojeda, Geert Uytterhoeven, Linus Torvalds,
Michael S. Tsirkin, Paolo Bonzini, Konstantin Ryabitsev, users,
tools
On Thu, 16 Oct 2025 10:20:44 +0200
"Vlastimil Babka (SUSE)" <vbabka@kernel.org> wrote:
> Perhaps a solution that would work universally on the sender side (not
> knowing particular receiver preference) and could be automated is to use
> "To:" when individual patch touches the code of given maintainer, and "Cc:"
> when it's not. People who only want to see their patches (plus cover letter)
> like Steven would then have a hopefully easy way (easier than by diffstat)
> to filter that out?
I'm not sure how much easier that would be. Looking at some of my other
emails, I can see the "to" section becoming quite large, and now I need to
find my name within 15 other names. Easier than a diffstat, but still more
likely to be ignored.
-- Steve
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 12:11 ` Mark Brown
2025-10-15 13:50 ` James Bottomley
@ 2025-10-15 14:37 ` Miguel Ojeda
1 sibling, 0 replies; 81+ messages in thread
From: Miguel Ojeda @ 2025-10-15 14:37 UTC (permalink / raw)
To: Mark Brown
Cc: Geert Uytterhoeven, Linus Torvalds, Michael S. Tsirkin,
Paolo Bonzini, Konstantin Ryabitsev, users, tools
On Wed, Oct 15, 2025 at 2:11 PM Mark Brown <broonie@kernel.org> wrote:
>
> Ccing people makes sense but doesn't need something in the patch body,
> and especially doesn't need to end up in the commit log.
I agree, i.e. I was talking about specific cases only (that are
manual), not the vast majority.
Cheers,
Miguel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 9:38 ` Miguel Ojeda
2025-10-15 12:11 ` Mark Brown
@ 2025-10-15 14:50 ` Steven Rostedt
1 sibling, 0 replies; 81+ messages in thread
From: Steven Rostedt @ 2025-10-15 14:50 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Geert Uytterhoeven, Linus Torvalds, Michael S. Tsirkin,
Paolo Bonzini, Konstantin Ryabitsev, users, tools
On Wed, 15 Oct 2025 11:38:41 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> Yeah, when they are added automatically as a big block (e.g. 10
> lines), it is not great.
I'm guilty of this, as my script adds all those that are Cc'd to a patch to
the commit body. It's used when somebody complains to me they didn't know
about a change, I can go back and say "but you were Cc'd on it".
But thinking about this. If we have a Link: tag to the commit that was
pulled in, that could be used in replace of Cc's. Because, then I can go to
the email patch itself and say "but you were Cc'd on it".
-- Steve
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 7:33 ` Geert Uytterhoeven
2025-10-15 9:38 ` Miguel Ojeda
@ 2025-10-15 13:51 ` Martin K. Petersen
2025-10-15 14:16 ` Konstantin Ryabitsev
2025-10-15 14:51 ` Geert Uytterhoeven
1 sibling, 2 replies; 81+ messages in thread
From: Martin K. Petersen @ 2025-10-15 13:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
Geert,
>> - patch ID
>
> Patch ID is not sufficient, because maintainers change patches
> regularly, for minor improvements, or because of small conflicts.
FWIW, the success rate for patch-id --stable lookups for *unmodified*
patches downloaded directly from lore was around 25% for me during the
last cycle.
With the edits I regularly do to fix typos, add line breaks, or
otherwise fix formatting, the effective patch-id hit rate is much lower.
>> - subject line and patch date (note: maybe from the email, maybe in
>> the body of the email)
>
> These may be edited by the maintainer, too, because of prefixes that do
> not match the subsystem style, or because of spelling/grammar/wording
> issues.
Exactly. So far, 'b4 dig' has not been able to identify very many
patches that weren't found via patch-id because of mismatched subject
lines.
I think this entire discussion misses the fact that many patch
submitters are unfamiliar with the subsystems they post patches to. So
the original subject will be "drivers: fix foo" even though it's clearly
a fix to a particular subsystem driver or component and should be tagged
accordingly. And inevitably subject lines, patch descriptions, and code
comments get tweaked as part of the commit process.
If we continue with a fuzzy searching scheme, then how do we accommodate
commits whose origin can no longer be identified? I'm sure b4 dig will
improve over time but there will always be a delta.
I tentatively added an Original-Patch-Id: <hash> tag to the patches I
had in my queue that could not currently be identified by 'b4 dig'
thanks to subject edits. But again, the existing lore patch-id hit rate
is low even for unmodified patches so I ended up with quite a few
commits which simply could not be matched up with anything on lore.
Also, why burden maintainers with all this? It really seems that we
would be much better off solving the problem of matching different
versions of the same patch or series on the kernel.org side. Patchwork
already does this. It would be appropriate for the lore archives to
maintain a similar mapping so one could easily check all versions of a
series and download an mbox of all discussions pertaining to a given
commit.
I think it would be incredibly helpful if people could reliably click on
a link in a given commit description and see everything that was ever
said on the patch in question. Both before and after the patch was
committed, any regressions reported at a later date, etc. And regardless
of which edits were made to the patch as part of the commit/merge
processes and any conflict resolutions. Also, to me there is a lot of
value in being able to see "no, there were no follow-ups or regressions
reported for this commit since I applied it N years ago". No data is
also information.
I don't have a problem with something like the commit SHA being the
principal patch UUID for lore lookups instead of Message-Id: if leaving
that in place is a deal breaker. But that still leaves the problem of
being able to establish a dependable link between a given commit SHA and
the "full history of the patch". Given how things are inevitably tweaked
as part of the development process, I really don't think patch-id is the
right tool for that job...
--
Martin K. Petersen
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 13:51 ` Martin K. Petersen
@ 2025-10-15 14:16 ` Konstantin Ryabitsev
2025-10-15 14:42 ` Miguel Ojeda
` (2 more replies)
2025-10-15 14:51 ` Geert Uytterhoeven
1 sibling, 3 replies; 81+ messages in thread
From: Konstantin Ryabitsev @ 2025-10-15 14:16 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Geert Uytterhoeven, Linus Torvalds, Michael S. Tsirkin,
Paolo Bonzini, users, tools
On Wed, Oct 15, 2025 at 09:51:20AM -0400, Martin K. Petersen wrote:
> With the edits I regularly do to fix typos, add line breaks, or
> otherwise fix formatting, the effective patch-id hit rate is much lower.
Do you normally edit them before applying, or after, when they are already
applied to a tree?
> Exactly. So far, 'b4 dig' has not been able to identify very many
> patches that weren't found via patch-id because of mismatched subject
> lines.
Linus would argue that in this case a Link: is warranted. :)
-K
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 14:16 ` Konstantin Ryabitsev
@ 2025-10-15 14:42 ` Miguel Ojeda
2025-10-15 15:03 ` Jason Gunthorpe
2025-10-15 14:55 ` [workflows]Re: " Steven Rostedt
2025-10-15 17:34 ` Martin K. Petersen
2 siblings, 1 reply; 81+ messages in thread
From: Miguel Ojeda @ 2025-10-15 14:42 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Martin K. Petersen, Geert Uytterhoeven, Linus Torvalds,
Michael S. Tsirkin, Paolo Bonzini, users, tools
On Wed, Oct 15, 2025 at 4:16 PM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Do you normally edit them before applying, or after, when they are already
> applied to a tree?
In my case, always after applying. I mainly use `b4` to get patches
successfully applied (ideally in their original base if any), and then
everything else within Git, including rebasing them etc.
Modifying patches for small details is a fairly common operation to
do, especially in areas with new contributors. I add the square
brackets [ ... ] to explain the changes performed, and then submit a
message including the square brackets (that way e.g. a new contributor
knows what to do next time, without having yet another iteration of
the patch series).
Cheers,
Miguel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 14:42 ` Miguel Ojeda
@ 2025-10-15 15:03 ` Jason Gunthorpe
0 siblings, 0 replies; 81+ messages in thread
From: Jason Gunthorpe @ 2025-10-15 15:03 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Konstantin Ryabitsev, Martin K. Petersen, Geert Uytterhoeven,
Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini, users, tools
On Wed, Oct 15, 2025 at 04:42:29PM +0200, Miguel Ojeda wrote:
> On Wed, Oct 15, 2025 at 4:16 PM Konstantin Ryabitsev
> <konstantin@linuxfoundation.org> wrote:
> >
> > Do you normally edit them before applying, or after, when they are already
> > applied to a tree?
>
> In my case, always after applying. I mainly use `b4` to get patches
> successfully applied (ideally in their original base if any), and then
> everything else within Git, including rebasing them etc.
This is my flow too. Everything is done in git after am. I rarely edit
the commits themselves (beyond am'ing them on a whatever base I happen
to have) but I frequently edit the commit messages for clarity, style,
etc.
Jason
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [workflows]Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 14:16 ` Konstantin Ryabitsev
2025-10-15 14:42 ` Miguel Ojeda
@ 2025-10-15 14:55 ` Steven Rostedt
2025-10-15 17:34 ` Martin K. Petersen
2 siblings, 0 replies; 81+ messages in thread
From: Steven Rostedt @ 2025-10-15 14:55 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Martin K. Petersen, Geert Uytterhoeven, Linus Torvalds,
Michael S. Tsirkin, Paolo Bonzini, users, tools
On Wed, 15 Oct 2025 10:16:37 -0400
Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Wed, Oct 15, 2025 at 09:51:20AM -0400, Martin K. Petersen wrote:
> > With the edits I regularly do to fix typos, add line breaks, or
> > otherwise fix formatting, the effective patch-id hit rate is much lower.
>
> Do you normally edit them before applying, or after, when they are already
> applied to a tree?
>
> > Exactly. So far, 'b4 dig' has not been able to identify very many
> > patches that weren't found via patch-id because of mismatched subject
> > lines.
>
> Linus would argue that in this case a Link: is warranted. :)
But knowing to add a link in this case is the hard part. My scripts add a
Link tag automatically. In most cases its useful because it helps with the
daisy chain of a patch. But in those small cases where the first patch gets
accepted, the Link tag added here is "useless" according to Linus. But I
still add it because my script does and I don't even think about the link
tags.
-- Steve
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 14:16 ` Konstantin Ryabitsev
2025-10-15 14:42 ` Miguel Ojeda
2025-10-15 14:55 ` [workflows]Re: " Steven Rostedt
@ 2025-10-15 17:34 ` Martin K. Petersen
2 siblings, 0 replies; 81+ messages in thread
From: Martin K. Petersen @ 2025-10-15 17:34 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Martin K. Petersen, Geert Uytterhoeven, Linus Torvalds,
Michael S. Tsirkin, Paolo Bonzini, users, tools
Hi Konstantin!
> On Wed, Oct 15, 2025 at 09:51:20AM -0400, Martin K. Petersen wrote:
>> With the edits I regularly do to fix typos, add line breaks, or
>> otherwise fix formatting, the effective patch-id hit rate is much lower.
>
> Do you normally edit them before applying, or after, when they are
> already applied to a tree?
Subject fixes and any tags are added to the b4 am output as part of my
initial, semi-automated patch validation scripting. Commentary, code, and
formatting changes typically happen after the initial commit passes
build and test. I don't want to invest time in fixing things up until I
have some level of confidence that the patch is correct.
--
Martin K. Petersen
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
2025-10-15 13:51 ` Martin K. Petersen
2025-10-15 14:16 ` Konstantin Ryabitsev
@ 2025-10-15 14:51 ` Geert Uytterhoeven
1 sibling, 0 replies; 81+ messages in thread
From: Geert Uytterhoeven @ 2025-10-15 14:51 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Linus Torvalds, Michael S. Tsirkin, Paolo Bonzini,
Konstantin Ryabitsev, users, tools
Hi Martin,
On Wed, 15 Oct 2025 at 15:51, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
> I think it would be incredibly helpful if people could reliably click on
> a link in a given commit description and see everything that was ever
> said on the patch in question. Both before and after the patch was
> committed, any regressions reported at a later date, etc. And regardless
> of which edits were made to the patch as part of the commit/merge
> processes and any conflict resolutions. Also, to me there is a lot of
> value in being able to see "no, there were no follow-ups or regressions
> reported for this commit since I applied it N years ago". No data is
> also information.
Exactly. And if all commits would have such a link, the "Patch
foo has been added to the bar-stable tree"-emails can be sent as
follow-ups, too. One ring to bind'em all.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 81+ messages in thread