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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 22 Apr 2025 at 15:42, Junio C Hamano <gitster@xxxxxxxxx> 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?

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux