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.
