customizing "cherry picked from commit abcd" comment

customizing "cherry picked from commit abcd" comment

[Rasmus Villemoes]

Hi,

When working on a custom U-Boot or linux kernel based of some vX.Y, I often end up
cherry-picking fixes from upstream. Using "cherry-pick -x" is nice, but
I usually amend the commit so that it doesn't just say

    (cherry picked from commit bfbbd8472edbcff1f530ef8e1d74c56af74ecf13)

but instead

    (cherry picked from commit bfbbd8472edbcff1f530ef8e1d74c56af74ecf13 aka v2025.01-rc2~35^2~5)

This makes it easier, when porting to v+1, to know if that commit still
needs to be cherry-picked or is already included, and also makes it
obvious to anyone reading the current history to know the "upstream
status" of that commit.

Now editing in that, which I get from "git describe --contains
--match=v*", is not too onerous, but I'd still like a way to automate
it. What I imagine is some config knob indicating an executable to call
with a single argument, the full sha1 of the cherry-picked commit, and
using that executable's stdout in lieu of the default -x message.

Of course, it's quite possible that the script cannot find anything
meaningful to say. So one would have to define what it means if it
prints nothing on stdout, and/or what it means if it exits
unsuccessfully. I'm leaning on saying "exit 0 => use stdout as-is, even
if empty; exit != 0 => fail the cherry pick operation", but I can
certainly be convinced that some other behaviour is more sensible,
e.g. having some combination indicate "fall back to the default
message".

Is this something that others could find useful, or is it too niche? If
the former, I'll try to cook up a patch, but I'd also like some input on
what the semantics should be, or if there's some other idea for
achieving the same thing without a custom callback.

Rasmus

Re: customizing "cherry picked from commit abcd" comment

[Oswald Buddenhagen]

On Mon, Sep 29, 2025 at 02:10:30PM +0200, Rasmus Villemoes wrote:
>This makes it easier, when porting to v+1, to know if that commit still
>needs to be cherry-picked or is already included, and also makes it
>obvious to anyone reading the current history to know the "upstream
>status" of that commit.
>
i sometimes customize this pseudo-footer as well, but it's usually 
things like "(partially cherry-picked ...)" or "(... from 
<repo>/<sha1>)", etc.

your particular use case would imo be better addressed by implementing 
bi-directional linking between picked commits via a standardized 
git-notes namespace.

the pseudo-trailer is really just a hack in the first place, and afaict 
that status quo results from an ideological commitment against 
cherry-picks during the early history of git. but it's really kinda 
silly that subversion and perforce have better tracking of cherry-picks 
to this date, even when it's their only way to do merges.

Re: customizing "cherry picked from commit abcd" comment

[Junio C Hamano]

Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:

> i sometimes customize this pseudo-footer as well, but it's usually
> things like "(partially cherry-picked ...)" or "(... from
> <repo>/<sha1>)", etc.

That does sound a sensible thing to do, assuming that the original
commit is public.  See below for a backstory why it is only a commit
object name and nothing else.

> 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 mde bidirectional, so in a workflow allows adopting this
great suggestion, it is a very sensible thing to do.

> the pseudo-trailer is really just a hack in the first place, and
> afaict that status quo results from an ideological commitment against
> cherry-picks during the early history of git. but it's really kinda
> silly that subversion and perforce have better tracking of
> cherry-picks to this date, even when it's their only way to do merges.

I do not know what "an ideological commitment" refers to in this
context, but if I recall correctly, the reason why I originally
added the "cherry picked from" message in 48313592 (Redo "revert"
using three-way merge machinery., 2005-08-27) was because of
end-user requests, and given that the linux-kernel was pretty much
the only large customer back then, I suspect it came from there.

The intention was for the original commit to be also be public and
in the same project (e.g., you cherry-pick a commit from the main
branch developing towards the next great version, down to a
maintenance branch for the previous release), which made the commit
object name alone an sufficient identifier (also, this way predated
the invention of "git show -s --format=reference", so it is really
a dry hexadecimal object name and nothing else).

Initially, the feature to add the message was enabled by default.
Without passing an option, you always got the message in the
cherry-picked result.

Later, it was found that people ended up many commits with "cherry
picked from" messages that refer to commit objects that are not
available anywhere, because they cherry-pick across their private
branches while developing their patches, and the practice started
littering the public commits with these "useless" (because they do
not point at any commits that are part of anybody's official
history) references to the original commits they were cherry-picked
from.  And this made us turn the feature off by default, adding the
message only when the user explicitly asks to do so.

Re: customizing "cherry picked from commit abcd" comment

[Oswald Buddenhagen]

On Tue, Sep 30, 2025 at 08:39:29AM -0700, Junio C Hamano wrote:
>Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
>> the pseudo-trailer is really just a hack in the first place, and
>> afaict that status quo results from an ideological commitment against
>> cherry-picks during the early history of git.
>
>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.

>The intention was for the original commit to be also be public and
>in the same project (e.g., you cherry-pick a commit from the main
>branch developing towards the next great version, down to a
>maintenance branch for the previous release), [...]
>
yes, exactly. this trunk-first development model is quite common, and 
has been strongly pushed by some big players in recent years. this makes 
it really surprising that git still does not provide well-integrated 
support for it out-of-the-box.

based on your response i conclude that you would actually welcome such a 
thing very much, but the impression of a bias against cherry-picks is 
probably not unique to myself, and if so, it likely contributed to the 
persistence of the status quo.

Re: customizing "cherry picked from commit abcd" comment

[Junio C Hamano]

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.  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.  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 preferrable.  That way, the fact that your
solution is applicable even down to the "oldest potential target" is
structually 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.

>>The intention was for the original commit to be also be public and
>>in the same project (e.g., you cherry-pick a commit from the main
>>branch developing towards the next great version, down to a
>>maintenance branch for the previous release), [...]
>>
> yes, exactly. this trunk-first development model is quite common, and
> has been strongly pushed by some big players in recent years. this
> makes it really surprising that git still does not provide
> well-integrated support for it out-of-the-box.

So, I am not sure exactly what you refer to "well-integrated
support" in this context.  Not cherry-picking and instead building
on the oldest potential target for your solution does take some
discipline, and there may not be a strong tool support to help
people pick the right fork point and merge up/down the fixes.

Making that easier would be a great addition and that would be very
much welcome, I would think.   

But I do not think I would approciate 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."

Re: customizing "cherry picked from commit abcd" comment

[Oswald Buddenhagen]

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

Re: customizing "cherry picked from commit abcd" comment

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On 2025-09-29 at 12:10:30, Rasmus Villemoes wrote:
> Is this something that others could find useful, or is it too niche? If
> the former, I'll try to cook up a patch, but I'd also like some input on
> what the semantics should be, or if there's some other idea for
> achieving the same thing without a custom callback.

I haven't looked, but I wonder if maybe you can use one of the commit
message hooks for this.  If you're creating that cherry pick, then you
might be able to automatically edit the message accordingly using some
sort of script.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]