On Thu, Apr 3, 2025 at 3:47 PM Martin von Zweigbergk <martinvonz@xxxxxxxxxx> wrote: > [...] > > 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. In my experience with Gerrit-based projects, it was actually pretty common... > > 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? It's quite common for projects with multiple supported LTS releases. Important fixes are backported to each LTS branch, and people typically check that the fix has been backported by looking for the same change id on other branches. In such projects, 'git switch <change-id>' feels non-sensical to me; which particular copy of that change-id from which branch would that switch you to? Or were the dozens of projects I was using that were hosted in Gerrit abusing change-ids in your view? If so, how would you get them to stop? If you don't have multiple LTS releases to support, or avoid backporting fixes, then I could see how you'd arrive at the conclusion that duplicate change-ids were rare, and then you could start using change-ids interchangably with commit identifiers in commands so long as you only tried it on such projects. But I'm a bit uncomfortable suggesting we just assume all projects fit that mold. Am I still missing something here?
