Subject: customizing "cherry picked from commit abcd" comment

From: Rasmus Villemoes <[email-masked]>
Date: Mon, 29 Sep 2025 14:10:30 +0200

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