On Thu, 3 Apr 2025 at 15:13, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > > 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@xxxxxxxxxxxxxxxx> 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. > > > > 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.
