On Thu, 3 Apr 2025 at 20:11, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > > 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. Jujutsu (and Mercurial) keep track of the set of visible heads. There can be branches but they are not necessary. When you rewrite a commit, Jutjutsu always rewrites all descendants. It also updates all branches pointing to those commits automatically. For example, if you update the description of some commit with `jj describe -m 'new description --revision xyz', then commit xyz and all its descendants will be updated, and any branches pointing to any of the rewritten commits will be updated. I think this is getting off topic. I can provide more detail to you in a private message if necessary, or maybe we should start a new thread. I don't know what the convention on this list is. Or join the Discord channel [1], or the #jujutsu channel on Libera.Chat. > > > 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. I agree that that can be one reason to use change IDs but I disagree that it's the only reason. Having a stable way to refer to an evolving commit is also important. > 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. This sounds more like the idea of "topics". It's an interesting discussion, but it seems off topic for this thread. > 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.) Yes, I understand that it would be significant work to add support in Git. I hope that Git can gain the feature eventually, but we have no expectation that it will be implemented soon, especially not the UX part (the preservation-on-rewrite part should be simpler, I think). [1] https://discord.gg/dkmfj3aGQN
