From: Nico Williams Date: Tue, 07 Apr 2026 20:13:39 GMT Subject: Re: [PATCH] headers: Preserve 'change-id' header in rebase / cherry-pick. Message-ID: In-Reply-To: On Tue, Apr 07, 2026 at 09:20:35AM -0700, Junio C Hamano wrote: > Nico Williams 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 " (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 --