Git: error when fetching master from origin

Question

I've been using the following command to update the local master when I'm not on master:

git fetch origin master:master

However, today, it stopped working on one of the repo clones I'm working on. It fails with an error:

fatal: refusing to fetch into branch 'refs/heads/master' checked out at '/path/to/project/directory'

On another clone of the same repo it works fine. Any idea what might be the cause? Note that I am not on the master branch when invoking the command.

I'm on macOS Monterey 12.6 (21G115) with Git 2.38.0 from Homebrew.

More info (anonymized):

$ git worktree list
/path/to/project/directory  aa00aa0a0a0 [my-current-branch]

$ git branch -vv
  main                 bb11bb1b1b1 Title of the commit on main
  master               cc22cc2c2c2 [origin/master] Title of the commit on master
* my-current-branch    aa00aa0a0a0 [origin/my-current-branch] Title of the commit on my-current-branch

There are more branches on the list but that shouldn't be relevant. You can see master & my-current-branch are up to date and main is not right now.

Also:

$ git remote show origin
* remote origin
  Fetch URL: [email protected]:my-org/my-repo.git
  Push  URL: [email protected]:my-org/my-repo.git
  HEAD branch: master
  Remote branches:
    main                 tracked
    master               tracked
    my-current-branch    tracked

The output here is huge as we have a lot of branches but other ones should be irrelevant. There's only a single remote: origin.

Answer 1

I just ran into this issue, and it had nothing to do with worktrees. In my case, I still had a bisect going, and the master branch was checked out outside the rebase. Check your git status to be safe.

Answer 2

The error message:

fatal: refusing to fetch into branch 'refs/heads/master' checked out at '/path/to/project/directory'

indicates that Git is certain that there is an added working tree. You should be able to see this working tree in git worktree list output, but if your Git is modern enough—and 2.38.0 certainly is—it should also show up in git branch -vv output, e.g.:

$ git worktree add ../xxx -b foo
Preparing worktree (new branch 'foo')
...
$ git branch -vv
+ foo             c3ff4ce (<path ending in xxx>) <commit subject>
* main            c3ff4ce <same commit subject>
  ...
$

What could have happened is that you did have an added working tree, but then you removed it, and git worktree prune cleaned it up:

$ git worktree list
<path1>                      c3ff4ce [main]
<path2, ending in xxx>       c3ff4ce [foo]
$ rm -rf ../xxx
$ git worktree prune
$ git worktree list
<path1>                      c3ff4ce [main]
$ 

Note that git worktree prune is a period maintenance task that git gc --auto will run if and when it thinks it should. (If you use git worktree remove to remove added working trees, pruning never does anything, but since it was designed with this kind of lazy update ever since Git 2.5 added git worktree add, the maintenance tasks still have to check.)

As for git fetch origin master:master itself, you added in a comment:

This is a common syntax for synchronizing a branch you are not on to its remote version and it worked fine so far...

I would not call it common myself, though it is known and mentioned in various StackOverflow answers. I would not recommend its use: don't do that, just refer to origin/master directly when you want to get the current hash ID stored in origin/master. If you're not actually using master here for anything, just go ahead and delete it entirely, so that you're not tempted to use it.

The one remaining note I'd add here is that since you're using a homebrew-installed Git on macOS, be aware of (and careful about) the multiple-Git-version issue: there's probably a /usr/local/bin/git or /opt/.../git and a /usr/bin/git, one being the Apple Git and one being the homebrew Git. Which one any particular command runs will depend on $PATH.