Git - Bare repo cannot have a worktree for master branch - WHY?

Question

I'm working on some server-side software to do a merge. By using git worktree it's possible to check out a given branch for a bare repo and merge another branch into it. It's very fast, even with large repositories.

The only exception seems to be merging to master. When I do git worktree add /tmp/path/to/worktree master I get an error:

fatal: 'master' is already checked out at '/path/to/bare/repo'

But this is clearly not true, git worktree list gives:

/path/to/bare/repo (bare)

...and of course, there is no work tree at that path, just the bare repo files you'd expect.

UPDATE: I got in touch with the git maintainers, and they have agree that this might be a bug. I have a preliminary patch from them to test. In addition, I have also been able to reproduce the desired behavior without the patch.

At this point I'm not entirely sure what the boundary condition or root cause is, and there might be a fix forthcoming from git.

Nonproductive

From reading the docs it seems you might need to pass the -b option to create a branch for this to work. – Ambiversion

Hm. But there is an existing master branch in this repo. The error message would seem to confirm that as well. Maybe it's not clear from my description above, but this approach works fine (no error messages) with other branches, including merging from master to another branch. – Nonproductive

Answer 1

Turns out that this is a bug in git, beginning with the worktree implementation in 2.5 and higher.

The bare repository still has a HEAD reflink. Whatever that link points to is considered by git (up to and including 2.10) to be the default branch for new cloners, and is (wrongly) treated as if it's on an active work tree.

I have received a patch from the git maintainers to fix this behavior, and it seems to work. Alternatively, it should be possible to use update-ref on the bare repo to switch from master temporarily.

I'll be testing both of these options.

Nonproductive

Answer 2

I think this is incorrect. You may want to report it to them. I could not find any discussion yet, though the case seems obvious.

As a workaround you can run git update-ref --no-deref HEAD 'HEAD^{commit}' . It detaches current HEAD, so that master becomes not checked out

Avellaneda