0

Following up on '<Branch>' is already checked out at '</other/location>' in git worktrees

I'm getting the "Branch is already checked out at different worktree" error when my branch and worktree mismatched:

I have to use git worktree remove to remove my 1.2T worktree for now, but I'd like to know what's the best way to fix it in the future.

I have branch and worktree setup like the following:

  • /path/master corresponds to my git master branch
  • /path/release-a corresponds to my git release-a branch
  • /path/release-b corresponds to my git release-b branch

So on and so forth. I had it like that for years, until a few days ago I click and change a worktree branch in MS VS by mistake. Now my branch and worktree is like this:

  • /path/release-a is using my git release-b branch
  • /path/release-b is using my git release-b branch

Now I cannot change it back in MS VS. Trying to switch branch within the worktree will get me:

fatal: '<branch>' is already checked out at '</other/location>'

Any better way other than git worktree remove please.

xpt
  • 20,363
  • 37
  • 127
  • 216
  • Consider running `git worktree prune` as in my answer there. – torek Mar 24 '21 at 22:55
  • Thanks but I've tried `git worktree prune` before posting here. I.e., it didn't help the above situation. – xpt Mar 26 '21 at 01:51
  • Hm, that suggests that VS is doing a `git worktree lock`. The latest Git (2.31 now) might have an improvement that's been in the works to make `git worktree list` show more information about the set of work-trees it knows (or thinks it knows) about, which might help here. Not sure what the state of this is at this time though. – torek Mar 26 '21 at 02:59
  • Thanks torek, I did looked up and tried `git worktree list` before, I've lost the output (due to my Windows machine was forcefully rebooted), but I do think there is nothing special about the mismatched worktree, else I'd have noticed and asked alone that route. I could be wrong though (or my git is not recent enough). Thanks for the info, may it help the next victim. – xpt Mar 27 '21 at 00:43
  • My question would be how you managed to change one of your work trees to have a branch checked out that you already had checked out in a different work tree. In other words, when whatever checked out `release-b` in `/path/release-a`, why didn't *that* command also get that same error message? Basically, you shouldn't be able to end up in this kind of situation. – Lasse V. Karlsen Apr 03 '21 at 21:44
  • As I have explained, _"I click and change a worktree branch in MS VS by mistake"_. You've got to have used MS VS to understand that black magic. – xpt Apr 04 '21 at 02:06
  • This corruption can be recreated by editing `/.git/worktrees/release-a/HEAD` to `ref: refs/heads/release-b`. How to undo that curroption is left as an exercise for the reader. – Guildenstern Apr 15 '23 at 11:13

1 Answers1

2

Hm, if the layout is as you described, you should just be able to git switch release-a within /path/release-a. Does your question reflect the output of git worktree list, or what you see in MSVS?

If the .git metadata is messed up, you could create dummy branches (git checkout -b dummy-x, dummy-y etc) in both worktrees, then git switch release-... back in each one. Commit / stash as necessary if there is unsaved work in the worktrees.

If MSVS stores metadata elsewhere, that's a different problem which presumably can only be solved within MSVS.

usretc
  • 723
  • 4
  • 9