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

[Nico Williams <nico@cryptonector.com>]

On Thu, Apr 03, 2025 at 03:05:41PM -0700, Martin von Zweigbergk wrote:
> 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.

> > > 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
--