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