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

From: Junio C Hamano <[email-masked]>
Date: Tue, 22 Apr 2025 15:42:25 -0700

"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.