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

From: Toon Claes <toon@iotcl.com>
Date: Jun 6, 2025, 13:04 UTC
Message-ID: <87plfh10nv.fsf@iotcl.com>
In-Reply-To: <CAESOdVCjc1kvQSKnxGfNNSTvFhLRjH_vzwMauP8ZWQ5hhfBnEw@mail.gmail.com>

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

Show 21 quoted lines

> On Wed, 23 Apr 2025 at 08:51, Junio C Hamano <gitster@pobox.com> wrote:
>> 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?
>
> Maybe it depends on how the forge uses the change id. If the forge is
> Gerrit, it will use the (change id, target branch) to identify a
> review (IIUC), so then it will require a new change ID because it
> requires a new review. If it doesn't have that requirement (maybe it's
> PR-style forge), then it could at least highlight to the reviewer that
> there was an old version of the change that has already been merged.

I've been thinking some more about duplicates.

First, I don't think you can enforce uniqueness. Whenever you're working with forks you can have commit A from fork I to have the same change-ID as commit B in fork II (because either of them might be rebased). Enforcing uniqueness on change-IDs would disallow the user to fetch from both forks, or they would need to specify how to resolve the change-id conflict.

I like Martin's idea of having forges ensuring uniqueness, but I was wondering if we should take it a step furter: a commit should not be able to reach another commit with the same change-id. Verifying this on the client-side, helps the user detect issues sooner. Only seeing that error when pushing to the forge might be annoying.

Anyhow on the other hand, what about merges? If people merge the 'main' branch into their feature branch, it would no longer be possible to merge the feature branch into the 'main' branch.

But to circle back to Junio's example. It depends on what you want to track. You could consider both changes to be different, and thus requiring different change-ids, because one didn't fix all of it.

-- 
Cheers,
Toon