Hi,
The Gerrit, GitButler, and Jujutsu projects all have a concept of
a "change id", and it behaves in a similar way between the three
tools. The change id is conceptually associated with a commit.
It follows a commit as its rewritten (e.g. by amending and
rebasing). The three projects currently store and format the
change id differently. We would like to unify that so we can
interoperate better. We hope the Git project is also interested
in preserving and using this header.
There are many benefits to having a change id even if it's just
local. I mentioned some in my email to this mailing list in [1].
For example, it enables
`git rebase main <change ID>; git switch <change ID>` without
requiring the user to look up the hash of the rewritten commit.
If the change id also transferred between repos and preserved by
a forge (such as Gerrit), it enables the change id to be used to
identify a code review.
Here's how the change ids are currently stored and formatted:
* Gerrit currently stores change ids in a commit trailer called
`Change-Id`. It always starts with the letter 'I' and is
followed by 40 hex digits. For example:
`Change-Id: Ib563e78c3fedcff262255fa025441daa3202311b`.
* GitButler currently stores change ids in a commit footer
called `gitbutler-change-id` (older versions used
`change-id`). It's written as 32 hex digits separated by
dashes as in the UUID format. For example:
`gitbutler-change-id 7d0fbc63-032d-413c-8ae8-610fbeb713c0`.
* Jujutsu currently stores change ids in a local storage outside
of the Git repo and is therefore not part of the Git commit
id. It is stored as 16 bytes. It is rendered to the user as
"reverse hex" using 'z' through 'k' as hex digits ('z' = 0,
'k' = 15). This allows even short prefixes to be distinguished
from commit ids, which is a very useful property when used in
the CLI.
As mentioned, the three projects would like to use the same
storage and format. I think we have a consensus to store it in a
Git commit header called `change-id` as a 32 reverse-hex digis.
For example: `change-id ywlktllmukprnxnmzzprukpuwyztylwt`.
There is a design doc [2] about the impact on Gerrit and how to
handle various cases where the client doesn't understand the
`change-id` header. That also includes some discussion about
whether cherry-picking should preserve the change id or create a
new one. I think there is a lot of value in having a
standardized header regardless of what we decide about
cherry-picks.
So, to be clear, this is mostly a heads up at this point; we don't
depend on any immediate changes from the Git project.
Thanks,
Martin
[1] https://lore.kernel.org/git/CANiSa6gwup5vXU235mG+Ybbc+P=SbwoNFEmuhg=iYu0yGvSXVA@xxxxxxxxxxxxxx/
[2] https://gerrit-review.googlesource.com/c/homepage/+/464287
