Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer
- From
Martin von Zweigbergk <martinvonz@google.com>
- Date
- Apr 3, 2025, 22:47 UTC
- Message-ID
- <CAESOdVAWWP=Rte4bx3zUZc6p0XiZaJS2OZr8ezRPkfq8K1TYfw@mail.gmail.com>
- In-Reply-To
- <Z+8IF67AC8gSouYc@ubby>
On Thu, 3 Apr 2025 at 15:13, Nico Williams <nico@cryptonector.com> wrote:
Show 17 quoted lines
> > 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`.
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.
> 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 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. I know Git often leaves descendant branches until you manually rebase them, but at least that's probably typically a pretty short-lived state. I had a script for this back when I used Git.
Show 18 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/ ?
The former.
> 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.