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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 7, 2026, 16:20 UTC
Message-ID: <xmqqtstm68to.fsf@gitster.g>
In-Reply-To: <adUoR/T17fKr+YLN@ubby>

Nico Williams <nico@cryptonector.com> writes:

Show 16 quoted lines

> On Tue, Apr 07, 2026 at 10:55:00AM +0100, Phillip Wood wrote:
>> On 07/04/2026 05:58, Nico Williams wrote:
>> > 
>> > Maybe that's the trick: local configuration for determining the
>> > copy-or-drop semantic for different operations, and maybe hooks for
>> > altering when copying.
>> 
>> I think the danger with making it configurable is that you cannot rely on
>> the semantics because they vary between commits created by different
>> authors. [...]
>
> 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.

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