Re: [PATCH] headers: Preserve 'change-id' header in rebase / cherry-pick.

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 7, 2026, 14:42 UTC
Message-ID: <xmqqcy0a7rya.fsf@gitster.g>
In-Reply-To: <adSO6zPwtFOWBcOw@ubby>

Nico Williams <nico@cryptonector.com> writes:

Show 13 quoted lines

>> Format is one thing, but what it means is much more important.  When
>> is it inherited?  What happens when you split a single commit into
>> three pieces, which piece, if any, among the resulting three will
>> inherit thee parent's?  Should rebase, cherry-pick, and replay
>> behave the same way (IIRC, rebase and cherry-pick behaves
>> differently while propagating notes).  Etc., etc.
>
> Exactly.  I remember I argued that cherry-pick and rebase should have
> the same behavior given that rebase is logically a script of
> cherry-picks, but others had strong arguments that the two should not
> have the same behavior (something which is not hard to implement if you
> make the inherittance / non-inherittance an option to cherry-pick has
> different defaults for cherry-pick than for rebase).

Yes. Even though I often feel irritated when I use cherry-pick and see the "amlog" note not propagate when I should have used rebase, I think it makes sense to allow cherry-pick and rebase to behavve differently. This is because rebase is a rewriting operation, where the old incarnation of the topic is discarded (other than that it can be resurrected from the reflog of the branch for the topic) and only the new incarnation will stay in the history, while cherry-pick is a duplicating operation, where the new copy is an adaptation of the original commit into a different context and both of them will stay in the history serving different purpose.

Show 5 quoted lines

> That the value of this header should not have a format imposed -- that
> much is certainly the case as far as consensus goes, I think.  Basically
> it should be site-local, for some definition of site.  But the tooling
> can just treat it as opaque, perhaps with hooks to do any interpretation
> of those values.

And there is nothing to prevent us from doing all of the above (and more) with trailers. The existing interpret-trailers mechanism may be lacking, but hopefully it gives enough framework to build on top to allow projects to customize what they want them to mean and how they behave.