Re: customizing "cherry picked from commit abcd" comment

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 2, 2025, 02:49 UTC
Message-ID: <xmqqa52ayq4q.fsf@gitster.g>
In-Reply-To: <aN0TVmEMXOyDZEwR@ugly.lan>

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

Show 5 quoted lines

>>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.

Show 9 quoted lines

>>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."