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

[Nico Williams <nico@cryptonector.com>]

On Mon, Apr 06, 2026 at 09:09:54PM -0700, Junio C Hamano wrote:
> 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.

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