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

Question

I started using git worktrees. It seems to work, but I'm getting this error when attempting to check out a branch in the cloned worktree:

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

How do I get around this without deleting the .git/worktrees directory?

Limitary

Then git worktree move can be of interest (with Git 2.17+, Q2 2018): see my answer below. – Clie

This is one of those features where to have it work smoothly you actually realize you need an entirely different approach to a VCS... – Calumniate

Answer 1

Git won't let you check out the same branch twice, because if you do, and then go to one of the two work-trees and make a new commit, you'll set yourself up for misery when you go back to the other work-tree.

If you have actually removed the other work-tree, simply run git worktree prune to make Git realize this. If you have not actually removed the other work-tree, don't check it out twice: it's no fun.

Snowonthemountain

I think I understand the risks. I'm running a Vagrant machine on the other worktree so I don't want to mess with the branches there. After making some changes on a Readme file on the cloned worktree I want to merge the changes upstream, meaning that I want to check out the branch from the main repo and push, then do a pull in the first location. – Limitary

I'd still say "don't do it". You can get the same effect without the risk: check out a new branch pointing to the same commit as the existing work-tree. Make your new commit on the new branch, and push the new branch to the upstream server under the old name: git push <remote> <newbranch>:<oldname>. Now you can git fetch && git merge --ff-only (or anything similar or equivalent) to pick up the changes in the other work-tree. – Snowonthemountain

Answer 2

If you search for "worktree" in the manual git-checkout(1) you'll find

git checkout --ignore-other-worktrees <branch>

But you probably just want to do the following so when you move (commit to) the branch in one worktree, the HEAD of the other worktree is not moved.

git checkout --detach <branch>

Palliate

Answer 3

How do I get around this without deleting the .git/worktrees directory?

You will have an easier time with Git 2.17+ (Q2 2018), since "git worktree" has learned 'move' and 'remove' subcommands.

See commit 7f19def (04 Mar 2018) by Eric Sunshine (sunshineco).
See commit ee6763a, commit cc73385, commit 78d986b, commit c64a8d2, commit 9f792bb, commit 9c620fc (12 Feb 2018), and commit 4ddddc1 (24 Jan 2018) by Nguyễn Thái Ngọc Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit bd0f794, 14 Mar 2018)}

In your case, you could move the existing worktree to the place you now wants it (when attempting to create a new worktree for the same branch).

worktree move: new command

This command allows to relocate linked worktrees.
Main worktree cannot (yet) be moved.

And:

worktree move: refuse to move worktrees with submodules

Submodules contains .git files with relative paths.
After a worktree move, these files need to be updated, or they may point to nowhere.

This is a bandage patch to make sure "worktree move" don't break people's worktrees by accident.
When .git file update code is in place, this validate_no_submodules() could be removed.

---

Note: before Git 2.21 (Q1 2019), "git worktree remove" and "git worktree move" refused to work when there is a submodule involved.
This has been loosened to ignore uninitialized submodules.

---

With Git 2.43 (Q4 2023), a message written in olden time prevented a branch from getting checked out saying it is already checked out elsewhere, but these days, we treat a branch that is being bisected or rebased just like a branch that is checked out and protect it.
Rephrase the message to say that the branch is in use.

See commit 2a49926, commit 92edf61 (07 Aug 2023) by Rubén Justo (rjusto).
^{(Merged by Junio C Hamano -- gitster -- in commit f5f23a4, 24 Aug 2023)}

branch: error message checking out a branch in use

^{Signed-off-by: Rubén Justo}

Let's update the error message we show when the user tries to check out a branch which is being used in another worktree, following the guideline reasoned in 4970bed ("branch: update the message to refuse touching a branch in-use", 2023-07-21, Git v2.42.0-rc0 -- merge).

Instead of is already checked out at, you will see is already used by worktree at.

This follows up Git 2.42 change.

Clie

Answer 4

Since you cannot checkout twice in both worktree and the original repository. How about checkout original repo to somewhere else before you checkout the worktree?

git -C </other/location> checkout <branch>~1
git -C <worktree> checkout <branch>

Specialistic

Or detach the HEAD at the other location without changing its working tree git -C </other/location> checkout -d. This has the benefit of keeping the index at the other location intact after you check out the branch again with --ignore-other-worktrees and commit to it. – Palliate

Answer 5

Simply go to the worktree directory of your desired branch, and it automatically checkout for you.

In my case, I have two long-running worktree that means two relevant branches beside the master.

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

There is one repository, but I have 3 separate folders beside each other for each branch above. And make the common changes in master. then merge it with both other versions.

Specific changes of each version will go in the corresponding folder as well, and the works on each project are isolated and IDE wouldn't be confused.

Hope that helps.

Kunkle

Answer 6

If you really want you can bypass this check, either by directly modifying the ref in the respective HEAD file, or by recreating the branch with the same name with e.g. git checkout -B master origin/master

As others have said, you need to know what you're doing though; branches are common to all worktrees, changing one in one worktree will immediately affect the status of your other worktree.

Dennie

Answer 7

In my case this happened when the branch wasn't checked out in the other worktree so I was really puzzled! However, I grepped for the branch name in .git/worktrees and discovered that that worktree was in the middle of a rebase of that branch that I had forgotten about. After git rebase --abort and a git checkout of some other branch in the worktree, the problem was resolved.

Silsbye

Answer 8

Note that this also happens if your $pwd has links in it. git should probably readlink -f on the $pwd prior to checking.

Edit: Or this may indeed be because I missed to call git worktree prune. Now it's working.

Schrimsher