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

From: Phillip Wood <[email-masked]>
Date: Tue, 7 Apr 2026 10:41:43 +0100

On 07/04/2026 05:09, Junio C Hamano wrote:
> Matt Stark <[email-masked]> writes:
> 
>> In the discussions on
>> https://lore.kernel.org/git/[email-masked]/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.
> 
>> * 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.

Indeed, copying the header is easy (though the patch does not support 
copying the header when the commit message is edited), but agreeing on 
the semantics seems to be much harder.

Thanks

Phillip