Subject: Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer

From: "Remo Senekowitsch" <[email-masked]>
Date: Thu, 03 Apr 2025 22:31:08 +0200

On Thu Apr 3, 2025 at 7:48 PM CEST, Theodore Ts'o wrote:
> On Thu, Apr 03, 2025 at 08:39:31AM -0700, Elijah Newren wrote:
>> 
>> But <change ID> isn't unique, right?  The whole point of having the
>> change ID is to preserve it despite edits (e.g. rebase, commit
>> --amend, cherry-pick), meaning that you end up with multiple commits
>> with the same <change ID>.
>
> It's supposed to be unique, but it isn't always.  I've certainly seen
> cases where it might not be, but that's arguably a bug.  I suspect in
> some cases it's because users are cutting and pasting commit
> descriptions, and sometimes when they rebase a patch series, patches
> will get collapsed or split apart --- especially when backporting to
> an older LTS release.
>
> Perhaps because of this, in some communities, their tooling in front
> of Gerrit will always regenerate the Commit-ID when doing a
> cherry-pick (For example, when cherry-picking from the development
> HEAD branch back to a release branch).
>
> So as a cauaionary note, as people use Change ID's in Gerrit today,
> sometimes the Change ID changes between rebases, and I've certainly
> seen cases where the sematic meaning of the commit has changed
> significantly without changing the Change ID.  So it's great as a
> hint, but in practice, at least today, it might not be completely safe
> to assume the semantics are as advertised....

That is all true. I would just say that some change-ids not being unique
doesn't systematically take away from the benefits. If a given change-id
is unique, you get all the benefits for that patch, independent of
the uniqueness of the other change-ids. If some patch changes a lot
semantically while keeping its change-id, that will degrade its review
history, but without affecting the review history of any other patch.

Remo