Re: Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer)

[Oswald Buddenhagen <oswald.buddenhagen@gmx.de>]

On Wed, May 14, 2025 at 07:38:58AM -0700, Junio C Hamano wrote:
>So I do appreciate that the wider Git ecosystem like Gerrit and JJ
>are talking to adopt "Change ID" with the same syntax and semantics
>(if they all can agree, that is), but I do not think it needs to
>affect Git at the object level.  From what I have heard so far, it
>certainly does not fit in the commit and tag object headers, but
>more like the usual trailer thing.
>
but it doesn't really speak against it, either. it's a rather subjective 
call whether 3rd party metadata should be included into the commit 
proper or bolted on via the commit message.
this is really quite similar to rfc822 headers, and no-one would 
seriously argue that "auxiliary" meta data should be stored somewhere 
else. in fact, the current recommendation is even to omit X- prefixes 
(rfc6648).

it certainly seems valuable to at least have an example that proves that 
git doesn't corrupt extra headers. however, that would be obviously 
insufficient for "proper" support in git itself, as creation, editing 
and display of these headers needs to be reliable and convenient as 
well.

the use case for change-ids is addressing evolving changes (be it 
locally or in online review systems), which requires a one-to-one 
mapping with a commit in the active working set (sans the fact that a 
change can exist on multiple branches). as such, the ambiguity that 
tracking the complete evolution of commits would create would be even 
actively counter-productive for this use case.

by extension, it is sometimes necessary to make a conscious decision 
which change-id a particular derived commit should have. for this, it's 
quite convenient to have it in the commit message, because this makes it 
easy to drop one (or both) change-ids when squashing (or splitting) 
commits. however, this could also be achieved by having a defined format 
for editing metadata from within the commit message editor (this can be 
already achieved by having prepare-commit-msg and commit-msg hooks, but 
it's messy and lacks standardization).

one argument against change-id trailers is that they are eye sores, in 
particular in small projects that don't use trailers otherwise. this is 
in fact a common argument against even optional use of gerrit for 
reviews. having a more "subtle" implementation in git upstream would 
certainly alleviate this.