On Thu, Apr 03, 2025 at 03:47:30PM -0700, Martin von Zweigbergk wrote: > 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. I work in detached HEAD mode almost all the time. And yeah, Git won't update refs when in detached HEAD mode because... what ref should it update? The whole point of detached HEAD mode is that it does not. > > 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 The whole point of change IDs for me is that if I need to backport bug fixes [0] then I can identify the bug fixes by change ID and then cherry-pick them onto support branches, which means that yes, there will be many commits with the same change ID, each on different branches. Besides backports another use case that leaves multiple commits with the same change ID is when I'm working on multiple different approaches to implementing some feature on a complex codebase. I might have two or three branches exploring different ways to implement some feature, and of course I would want to use the same change IDs for similar commits even if I didn't use cherry-pick to create all but the first. Here's a third use-case that's quite real for me at $WORK where I have repos for Debian-style packaging and use different branches for different OS releases. Some such pkgs are ones that we patch locally, so each release-specific branch targets a different OS release, but they all mostly have the same contents, in which case this is similar to backports. Other pkgs are locally developed and rarely differ on different OS releases but occasionally they have to for <reasons> -- this is not similar to backports. [0] Granted, the industry has moved away from backports. But many open source projects still backport security fixes. E.g., OpenSSL, PostgreSQL, etc. So this is relevant. > 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. [...] No matter what you will not have a guarantee of one commit for any given change ID. Therefore `git switch $change_id` is not workable, not without interaction, and even then still not workable because Git might have to search _many_ branches to find commits matching the given change ID. (Fossil could have an index on change ID and trivially make that search possible, but for Git adding an index is more complicated.) > > 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. Even if cherry-picking were not common it's supported, therefore you can't have change IDs be unique like this. That doesn't make change IDs useless -- on the contrary, their utility comes from the fact that they are not repo-wide unique! Nico --
