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

From: "Remo Senekowitsch" <[email-masked]>
Date: Wed, 23 Apr 2025 01:21:12 +0200

On Wed Apr 23, 2025 at 12:42 AM CEST, Junio C Hamano wrote:
> "Remo Senekowitsch" <[email-masked]> writes:
>
>> Btw. since the thread was started, the implementation in Jujutsu has
>> been completed and I've been pushing commits with the change-id header
>> to various remotes for a while now. It works well. Forges can start
>> taking advantage of it. (I hope I find time to help work on that.)
>
> It should work well, until somebody finds your random is not random
> enough, right?  Unlike our object name that depends on the contents
> (hence a duplicate unless the cryptographic hash function collides
> means they are truly the same commit), there is no grabally unique
> ID assigner involved in your implementation, right?  Until
> sufficiently large number of people start using and large number of
> changes gets assigned IDs, it won't become an issue, but then how
> would it be different from what was raised in the earlier discussion
> to use the commit object name itself as the change ID for a commit
> that is not derived from anybody else, and copy that ID to commits
> that are derived from the original commit as the change ID shared
> among them?  At least that would give us a much better uniqueness
> guarantee, wouldn't it?  If you want to be able to tell between
> commit object name and change ID, I wouldn't object if you encode
> them using whatever mechanism.

Random number generators are well suited for this purpose, the only
requirement is that the distribution of generated numbers does not
massively deviate from a uniform probability distribution.

Commit hashes have 160 bits of information, the change-ids used by
Jujutsu today have 128 bits. That's still plenty to make random
collisions practically irrelevant.

And anyway, the situation of colliding change-ids will be somewhat of
a normal event due to cherry-picking etc. Jujutsu can deal with this
situation just fine today. Colliding change-ids are simply not as much
of a problem as colliding commit hashes.