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

[Nico Williams <nico@cryptonector.com>]

On Thu, Apr 03, 2025 at 08:39:31AM -0700, Elijah Newren wrote:
> On Wed, Apr 2, 2025 at 11:48 AM Martin von Zweigbergk
> > 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.
> 
> 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>.
> 
> Why would this work?

I agree that `git rebase main <change ID>; git switch <change ID>` is
not a good UI, and I wouldn't want it even though I want change IDs.

Change IDs are documentary, and they help people understand that various
commits are just edits/rewrites of the same original commit.

> And if it does work, isn't it expensive since you'd need to walk
> history to find it?  Or do you keep an extra lookup table on the side
> somewhere?

Worse: since there can be many commits with the same change ID they
can't be used as refs because Git can't possibly be expected to find
_the one_ you really intend -- how could it?  I suppose Git could let
you pick from a list, but that's not likely going to have enough
context.  Maybe Git could give you a list of named branches in which it
found some change ID's commits to pick one branch from, or maybe one
could `git cherry-pick --from $some_branch $cid` and have Git find the
commit(s) on `$some_branch` that match change ID `$cid`.

Also, maybe commits need to support multiple change IDs.  For example,
one might want one change ID for a set of commits (eg implementing a
feature), and each commit in the set having a second and more unique
change ID for just that commit (and all edits/rewrites of it).

> Yaay, I always hated it as a trailer.

More headers is better.

> cherry-pick & rebase preserve author name, email & time, while
> creating a new committer name, email, & time.  To me, the change-id is
> about the authorship, and since these commands already preserve
> authorship, it'd seem weird to me to have cherry-pick not preserve the
> change-id by default.

+1.  Besides, rebase is just a a bunch of cherry-picks, so cherry-pick
is the fundamental operation here.  If rebase is to preserver change-id
then so is cherry-pick.

Nico
--