How can I recover from 'fatal: reference is not a tree: master'?

Question

I have a git folder, which has two branches, master and working.

for reasons I cant explain, when I run a git branchcommand, I get three branches:

• desktop.ini
• master
• working

The working branch is up to date (after a reset), and has what I want in it.

The desktop.ini branch is not supposed to exist. When I run

git branch -d desktop.ini

it says that it doesn't exist and can't be deleted. It also can't be checkout out. There is a desktop.ini file in each folder in the Git repo, as it is a Google Drive folder in which the repo is stored.

The main problem, however, is that I can no longer access the master branch. Every time I try

git checkout master

I get back

fatal: reference is not a tree: master.

If I try deleting it, I get

error: couldn't look up commit object for refs/heads/master

Having checked manually this file does exist in the correct directory, and has a head inside it.

I also tried creating a new master branch, but was told a branch named "master" already exists. Finally, running git log gave the most recent commit, and then

error: could not read c7d68...blah blah
fatal: failed to traverse parents of commit aed8af.....

Is there any easy way of resuscitating the master branch?

UPDATE: copied the head from the working branch to the master branch, i now have access again to master. However every git statusreturns

error: could not read c7d68.....
error: could not read c7d68.....
fatal: Failed to traverse parents of commit aed8......

Do I need to act to correct this?

Answer 1

I ran into this problem myself this morning.

In my case I'm running an Ubuntu VM on a Windows host. The Ubuntu VM is used for development, but the files I'm working with are actually in a directory shared from the host OS.

Windows wont allow adding desktop.ini files to all the directories in the shared directory... including the .git directory and all of its subdirectories. Git is seeing these files in places where it's not expecting a third party to be manipulating the contents; so when I execute git branch I get a listing very similar to that of the questioner.

The key here is that these obviously aren't real branches. They're just files in places where Git is expecting to be able to do a simple enumeration of directory contents in order to find what branches exist. When you try to do something more substantial, like delete this new desktop.ini branch, it fails because it's not a real branch.

I resolved this very simply by deleting all the desktop.ini files that were added to the .git directory structure by Windows.

As soon as I did that, the phantom branches went away and everything worked fine (it was screwing up git-flow in my case since git-flow saw file in .git/refs/release as a current release in progress branch). I do expect these to come back if I continue to host these files in the Windows host file system.

There may be a more permanent way to prevent this, but I haven't gotten there yet.