From: Phillip Wood Date: Tue, 07 Apr 2026 09:41:43 GMT Subject: Re: [PATCH] headers: Preserve 'change-id' header in rebase / cherry-pick. Message-ID: <8f485b7f-3f6c-454c-8e87-d96ad8fa616c@gmail.com> In-Reply-To: On 07/04/2026 05:09, Junio C Hamano wrote: > Matt Stark 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. > >> * 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