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

[Nico Williams <nico@cryptonector.com>]

On Tue, Apr 22, 2025 at 04:49:13PM -0700, Junio C Hamano wrote:
> 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
> [...]

Is that really true?  Yes, because if two different objects have the
same hash then the first one pushed to a repository will "win" and the
second's content will never appear, right?  I suppose that the server
could detect the collision at push time and reject the push to make sure
that there's no surprises for the pusher.

But Git requires objects and refs to be unique _and_ it indexes by them.
This is great.  It might be fine for change IDs too, or not.

But remember that proponents want change IDs to not quite be unique,
since the point is that they tie multiple different versions of a commit
series together for the purpose of code review.  In the end, when the
code review is completed and approved then the change ID might be unique
again, but then cherry-picking onto other branches for forward- or
back-porting might render them non-unique again.

If you accept change IDs, I highly recommend not requiring them to be
unique.

Nico
--