On Wed Apr 23, 2025 at 12:42 AM CEST, Junio C Hamano wrote: > "Remo Senekowitsch" <remo@xxxxxxxxxxx> 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.
