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

From: Nico Williams <nico@cryptonector.com>
Date: Apr 7, 2026, 04:58 UTC
Message-ID: <adSO6zPwtFOWBcOw@ubby>
In-Reply-To: <xmqqqzor76nh.fsf@gitster.g>

On Mon, Apr 06, 2026 at 09:09:54PM -0700, Junio C Hamano wrote:

Show 11 quoted lines

> Matt Stark <msta@google.com> writes:
> 
> > In the discussions on
> > https://lore.kernel.org/git/Z_OGMb-1oV0Ex05e@pks.im/T/#m038be849b9b4020c16c562d810cf77bad91a2c87,
> > it seems to be that:
> > * There is consensus that a `change-id` header provides good value
> 
> I doubt it.
> 
> There are multiple people who wanted it, but as far as I can recall,
> I did not get the sense that they had the same semantics in mind.

The less semantics it has, the more acceptable it might be :) But then what would need patching? So it needs _some_ semantics.

Finding the minimal acceptable semantics for this header is the trick to pull.

Show 8 quoted lines

> > * There is not consenus on what precise format that should take
> 
> 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).

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.

Maybe that's the trick: local configuration for determining the copy-or-drop semantic for different operations, and maybe hooks for altering when copying. Thus for example splitting a commit (something jj supports directly but Git doesn't, unless I missed something) could derive or create new change-id values from the original using hooks. A hook might do things like create child or sibling problem tickets, or might only qualify the original with some qualifier. A hook might even interact with the user to create new change-ids as needed.

The risk here is that this could yield too much configuration and be more annoying than useful, but I think that wouldn't turn out to be the case.

Nico