Re: customizing "cherry picked from commit abcd" comment

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

On Wed, Oct 01, 2025 at 07:49:25PM -0700, Junio C Hamano wrote:
>Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
>>>I do not know what "an ideological commitment" refers to in this
>>>context,
>>>
>> it refers to the general notion "don't cherry-pick, but merge", which
>> relegates cherry-picks to being a 2nd-class workflow.
>
>Ah, that is not ideological at all, but aversion against
>cherry-picking is purely technical.
>
yes, but it presumes idealized circumstances, which aren't always 
realistic. insisting on it regardless makes it ideological.

>With only "cherry picked from" trailer, there is no structural link 
>between the commit that introduced the original change and the 
>resulting commit.
>It would make it impossible to automatically and reliably take previous 
>cherry picks into account when merging back a side branch or older 
>maintenance track that are riddled with cherry picks.
>
that's a circular argument, because it refers back to the current 
(rather bare-bones) implementation of cherry-picks.

>Compared to
>that, a more disciplined approach to (1) fork a topic from the
>oldest potential target of eventual cherry pick and develop your
>solution there, (2) merge the result to the mainline first, per
>trunk-first philosophy, (3) then merge the same down to the older
>targets, is always preferable.  That way, the fact that your
>solution is applicable even down to the "oldest potential target" is
>structurally encoded in the history even at step (1) by the choice of
>the fork point, and with (2) and (3), it is obvious from the history
>structure that the mainline and the older target both have the same
>solution applied.
>
well, yes, this sounds very nice ... "on paper".

but in reality, most people (incl. devs) aren't particularly disciplined 
by default, and it's a bit naive/presumptuous to think that one could 
educate them by withholding features that would make the result of 
suboptimal processes suck less (cf. the recent discussion about 
automating sign-offs [1]).

but let's assume an ideal culture where people are actually committed to 
doing things the right way. then we still face a host of practical 
problems:

firstly, it's often not obvious what the oldest target branch should be.  
improved tooling (that can be realistically implemented) would go only 
part of the way, because the reasons for fixes failing in old branches 
are often subtle and unexpected. therefore, it is much more practical to 
to actually fix the trunk first, and then opportunistically try to 
backport branch-by-branch as far as the trade-offs are deemed 
reasonable.

secondly, in your model, the fix needs to be tested on both its primary 
target branch and each newer branch it gets merged to - a priori, before 
it gets merged anywhere. in a big project with CI runs taking hours (and 
being flaky, as they always seem to be), this is a _massive_ practical 
problem.

thirdly, it happens often enough that the merge isn't clean, or some 
logical conflict occurs (see first point). in that case one has to 
"hide" the fixups in the merge commits (which makes it incredibly hard 
to follow them later on), or pile fixup commits on top (making things 
non-atomic, which also doesn't help). in such cases it is much more 
"honest" to actually have entirely separate commits on the branches, 
with only weak links between them.

lastly, even if everything goes well, the resulting overall history is a 
tad hard to comprehend when many fixes and branches are involved (the 
benchmark being "gitk --all"). linked cherry-picks would still have to 
be visualized, so the problem wouldn't go away entirely, but weak links 
could be shown in a way that does not distract from the core tree 
structure (in a cherry-pick-only model, the only merges are those of 
feature branches to trunk, so the release branches actually form a tree, 
not a dag, and are therefore much easier to follow).

>I am not sure exactly what you refer to "well-integrated support" in 
>this context.
>
- built-in tools actually use it to its full potential
- 3rd-party tools make heavy use of it, thanks to it being standardized
- manual intervention is rarely necessary, everything "just works"

>But I do not think I would appreciate the vague "well, this is not
>parent-child ancestry relation at all, but this commit and the other
>commit that is totally unrelated in the history space are somehow
>related, so let's add a random commit header to record such a vague
>ill defined notion that they are somehow related, and force the tool
>to pay attention to it somehow via magic."
>
ehm.
to quote two mails back:

On Tue, Sep 30, 2025 at 08:39:29AM -0700, Junio C Hamano wrote:
>Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
>> your particular use case would imo be better addressed by 
>> implementing bi-directional linking between picked commits via a 
>> standardized git-notes namespace.
>
>A nice property of notes is that they can be added after the fact 
>and can be made bidirectional, so in a workflow that allows adopting 
>this great suggestion, it is a very sensible thing to do.

that is our baseline.

in the mean time, i've been thinking a bit further:

why would we stop at cherry-picks? we can also track rebases and amends, 
thus addressing all the good questions raised in the recent thread about 
standardizing change-ids [2].

in fact, we would _have_ to track commit rewrites, as the cherry-pick 
links would become stale otherwise. but this can be recorded as even 
weaker provenance info in its own right, which would then serve to track 
the evolution of commits.

of course, links to short-lived commits would become stale, so they 
would need to be garbage-collected.

lots of details to think about ...

[1] https://lore.kernel.org/git/aCM5JY25NVPgyYRP@chrisdown.name/T/#u
[2] https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/T/#u