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

[Nico Williams <nico@cryptonector.com>]

On Tue, Apr 07, 2026 at 09:20:35AM -0700, Junio C Hamano wrote:
> Nico Williams <nico@cryptonector.com> writes:
> > Well, I said "site-local" and "for some definition of site", and the one
> > I had in mind is that the upstream provides this [default] configuration
> > for clones.  Sure, authors could override this locally, but presumably
> > they wouldn't, and presumably upstreams would check for adherence to
> > their rules.
> 
> This does sound quite sensible.  What you called "site", I called
> "project" in my earlier responses.
> 
> Some projects do already check that the changes are signed off with
> the "Signed-off-by" trailers.  If change-id or original-change-id or
> whatnot are deemed essential to a project, and are expected to be
> formatted in certain ways, the project will certainly validate them.

Cool!  Maybe we can achieve consensus.  Here's a strawman:

 - upstreams publish (where?) a set of policies for

    - change-id
    - original-change-id

   regarding:

    - commit splits
    - commit squashes
    - cherry-picks
    - rebases

 - these policies should reference named hooks that have to be locally
   installed in the clone (that way the upstream can't just cause
   arbitrary remote execution clone-side) -- hooks that can transform
   change IDs

We should probably also have options for cherry-pick and rebase that a
user can use to provide useful context such as "this is a backport to
...", or "this is for <ticket>" (adds change-id).

Hooks could do things like create child tickets, etc.

Punting all semantics to hooks and upstream policies leaves only generic
things to decide, namely: what operations call what hooks.  And that
should leave us nothing to argue passionately over.

> None of that requires us to hide this information in the commit
> object header, by the way.  And indeed, it is easier to validate
> what is in the "git log" output (where optional header elements like
> "encoding" are not shown).

Yes, for sure, this could just be commit message formatting practices
enforced by hooks.  In this case there should be a hook for extracting
change ID(s) from a commit message.

Nico
--