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 03:42:25PM -0700, Junio C Hamano wrote:
> "Remo Senekowitsch" <remo@buenzli.dev> 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

Eh, if the hash function is weak then collisions might not be so rare,
especially when intentional.

In a content addressed storage system hash collisions are (can be) bad,
but typically the hash functions used are good enough that collisions
are tolerable, and one just assumes that if the hash matches then the
data is right, and there is no way to verify that that does not require
trusting the hash function.

> ID assigner involved in your implementation, right?  [...]

Change IDs for this purpose need not be unique, IMO.  If they get
duplicated either you can notice the problem before pushing, or you can
accept the dups and use context to resolve them correctly as needed.

One could make every commit have the same change ID, as a joke or spam,
but presumably most upstreams wouldn't do that.

Using ticket IDs as change IDs implies a globally unique ID assigner,
and should work well enough where things like bugzilla are used.

Nico
--