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

From: Nico Williams <nico@cryptonector.com>
Date: Apr 3, 2025, 22:13 UTC
Message-ID: <Z+8IF67AC8gSouYc@ubby>
In-Reply-To: <CAESOdVAd+X=6nEULHtKKotH_W5yNaJAcUajRU79EuG+0SF3m1A@mail.gmail.com>

On Thu, Apr 03, 2025 at 03:05:41PM -0700, Martin von Zweigbergk wrote:

Show 10 quoted lines

> On Thu, 3 Apr 2025 at 11:10, Nico Williams <nico@cryptonector.com> wrote:
> >
> > 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.
> 
> Why do you think it's not a good UI? Is it because the change ID isn't
> meaningful? That's correct, but they are also very convenient. The
> unique prefix is usually two letters or so, depending on how many
> "local" commits you have in your repo. That makes them easy to type. I
> basically never refer to a commit by a branch name anymore.

What would `git rebase main <change ID>` do? I assumed that it would find a commit `<change ID>` in the current branch and rebase it onto the main branch. That seems workable, I suppose. It would be akin to `git cherry-pick --from $branch --change-id $change_id`.

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.

Show 15 quoted lines

> > > 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`.
> 
> See my reply to Elijah. There's usually just one visible commit with a
> given change id a repo.

s/a repo/in a repo/ ? s/a repo/in a branch/ ?

I'd expect many commits with the same change ID in a _repo_, but at most one in a _branch_. Except see my other comments about having a second kind of change ID to identify a set of related commits (e.g., if you have a rule that features, bug fixes, and tests all must go in separate commits, which some do, so you might need to have a main commit for some feature, several commits with fixes to earlier bugs required for that feature, and several test commits, all related to that feature).

Nico