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