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

From: Martin von Zweigbergk <martinvonz@google.com>
Date: Apr 23, 2025, 05:07 UTC
Message-ID: <CAESOdVDG_tfrWMvV6V_Ad76EqXU3Be+EpJDLvtgPcfCRHoJoYQ@mail.gmail.com>
In-Reply-To: <xmqq8qnr3jji.fsf@gitster.g>

On Tue, 22 Apr 2025 at 15:42, Junio C Hamano <gitster@pobox.com> wrote:

Show 13 quoted lines

>
> "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
> ID assigner involved in your implementation, right?

A forge can decide to enforce that no two commits on the main branch have the same change ID, for example.