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

From: Nico Williams <[email-masked]>
Date: Thu, 3 Apr 2025 22:11:21 -0500

On Thu, Apr 03, 2025 at 03:47:30PM -0700, Martin von Zweigbergk wrote:
> I think part of the problem is that I didn't consider that Git doesn't
> really like to work in detached HEAD mode and doesn't automatically
> update refs pointing to rewritten commits. This does take away a lot
> of the usefulness, unfortunately. It would still be a bit useful as an
> argument to readonly commands.

I work in detached HEAD mode almost all the time.  And yeah, Git won't
update refs when in detached HEAD mode because... what ref should it
update?  The whole point of detached HEAD mode is that it does not.

> > What would `git switch <change ID>` do?  `git switch` switches between
> > branches, but a change ID can't possibly identify a branch since many
> > commits could exist with the same change ID all in different branches.
> 
> Yes, the same change id *can* exist on many branches, but it's pretty
> uncommon. It might happen after cherry-picking, depending on what we

The whole point of change IDs for me is that if I need to backport bug
fixes [0] then I can identify the bug fixes by change ID and then
cherry-pick them onto support branches, which means that yes, there will
be many commits with the same change ID, each on different branches.

Besides backports another use case that leaves multiple commits with the
same change ID is when I'm working on multiple different approaches to
implementing some feature on a complex codebase.  I might have two or
three branches exploring different ways to implement some feature, and
of course I would want to use the same change IDs for similar commits
even if I didn't use cherry-pick to create all but the first.

Here's a third use-case that's quite real for me at $WORK where I have
repos for Debian-style packaging and use different branches for
different OS releases.  Some such pkgs are ones that we patch locally,
so each release-specific branch targets a different OS release, but they
all mostly have the same contents, in which case this is similar to
backports.  Other pkgs are locally developed and rarely differ on
different OS releases but occasionally they have to for <reasons> --
this is not similar to backports.

[0] Granted, the industry has moved away from backports.  But many open
source projects still backport security fixes.  E.g., OpenSSL,
PostgreSQL, etc.  So this is relevant.

> decide there, but it should very rarely happen in other cases. When
> you rewrite a commit, the old commit usually becomes unreachable, so
> if your change id resolved to one commit before the rewrite, then it
> will resolve to one commit after the rewrite. [...]

No matter what you will not have a guarantee of one commit for any given
change ID.  Therefore `git switch $change_id` is not workable, not
without interaction, and even then still not workable because Git might
have to search _many_ branches to find commits matching the given change
ID.  (Fossil could have an index on change ID and trivially make that
search possible, but for Git adding an index is more complicated.)

> > I'd expect many commits with the same change ID in a _repo_, but at most
> > one in a _branch_.
> 
> There may be multiple commits with the same change ID in a repo if you
> had cherry-picked the commit, depending on what we decide to do with
> the change ID on cherry-pick. But cherry-picks are not very common
> anyway. Or maybe it's common in some workflow? Oh, are you thinking of
> a scenario where you cherry-pick your own commit to see if an
> alternative approach is better? Sure, if cherry-pick preserve the
> change ID, then you would have multiple commits with the same change
> ID in that case.

Even if cherry-picking were not common it's supported, therefore you
can't have change IDs be unique like this.  That doesn't make change IDs
useless -- on the contrary, their utility comes from the fact that they
are not repo-wide unique!

Nico
--