Re: customizing "cherry picked from commit abcd" comment
On Wed, Oct 01, 2025 at 07:49:25PM -0700, Junio C Hamano wrote:
Show 10 quoted lines
>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.
Show 7 quoted lines
>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.
Show 12 quoted lines
>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"
Show 7 quoted lines
>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:
Show 8 quoted lines
>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
