Re: customizing "cherry picked from commit abcd" comment

[Junio C Hamano <gitster@pobox.com>]

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