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

From: Junio C Hamano <[email-masked]>
Date: Tue, 07 Apr 2026 07:42:05 -0700

Nico Williams <[email-masked]> writes:

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

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