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

[Junio C Hamano <gitster@pobox.com>]

Nico Williams <nico@cryptonector.com> writes:

> Change IDs for this purpose need not be unique, IMO.  If they get
> duplicated either you can notice the problem before pushing, or you can
> accept the dups and use context to resolve them correctly as needed.

Not having to worry about duplicates (as long as you trust Git well
enough not to worry about object name collisions) is a powerful
thing, though.  Unless there is a strong reason to stick to slightly
shorter (like 160-bit vs 128-bit) random string, being able to
directly compute the object name of the very first iteration is also
a plus, if you choose to use its commit object name as its change ID
(hence you do not have to worry about how you come up with a new ID)
possibly in some encoded form (if you want to be able to use both
object name and change ID in your UI), and have later iterations
record the same change ID in the trailer would be quite simple,
robust, and would be just as useful, if not more, as a scheme that
uses randomly generated string as change ID.

In any case, I am not all that interested in how change ID is
assigned than what its semantics would be and how it would help
keeping track of the changes made to changes.  Personally, I am
uninterested in a scheme that does not let me even tell which one
among many commit objects that share the same change ID is the
original and how they evolved (in other words, how they relate to
each other).

Thanks.