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

[Junio C Hamano <gitster@pobox.com>]

Martin von Zweigbergk <martinvonz@google.com> writes:

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

Would it make sense, though?  Imagine that a contributor in your
project did not refactor code properly and instead made a
copy-and-paste duplicates of a very similar code.  I find a bug in
one of them, without realizing that the old mistake of duplicating
code (instead of making it a shared helper that is called from the
two places) and create a fix for it.  Later somebody else realizes
the same fix is needed for the other copy---attempting to cherry
pick the original fix may find that remaining copy of a buggy code
as the logic to perform a three-way merge across renames that is
sufficiently clever kicks in.  Shouldn't these two commits to fix
the same bug in two places share the same change ID so that it is
clear to the later developers that the latter fix was derived from
the former one?