25

I save my repo in dropbox, and one day (see date below) it went crazy. Now I get these warning every time I try to autocomplete a branch name

warning: ignoring ref with broken name refs/heads/develop (MacBook Pro's conflicted copy 2015-02-28)
warning: ignoring ref with broken name refs/heads/master (MacBook Pro's conflicted copy 2015-02-28)
warning: ignoring ref with broken name refs/remotes/origin/develop (MacBook Pro's conflicted copy 2015-02-28)
warning: ignoring ref with broken name refs/remotes/origin/master (MacBook Pro's conflicted copy 2015-02-28)
warning: ignoring ref with broken name refs/remotes/production/master (MacBook Pro's conflicted copy 2015-02-28)

How do I fix these warning?

Note: For all the duplicate-trigger-happy people - this is not a dup! I just want to remove the references above to stop getting the warning. The git repo is intact

Chris Maes
  • 35,025
  • 12
  • 111
  • 136
Nick Ginanto
  • 31,090
  • 47
  • 134
  • 244
  • possible duplicate of [Git repository broken after computer died](http://stackoverflow.com/questions/15317072/git-repository-broken-after-computer-died) – cmbuckley Mar 06 '15 at 07:40
  • this is not a duplicate! I don't have the problem in that question. the git repo is intact. I just want to remove those references – Nick Ginanto Mar 06 '15 at 07:46
  • 4
    As a general comment: Things like this show why Dropbox is not a perfect solution for hosting a Git repo. Take a look at something like BitBucket, which offers free private Git repos. This might a better fit, and will avoid problems like the above. – nwinkler Mar 06 '15 at 10:04
  • I have it on github, but I noticed it after commiting code to the local repo – Nick Ginanto Mar 06 '15 at 13:11
  • 4
    @nwinkler I'd be worried about Dropbox *corrupting* my git repositories. (This here is even a small corruption, but fortunately, it can be recovered from, assuming you didn't lose your latest local commit on a branch or something.) Don't use something like Dropbox to manage something that's already under source control. – jpmc26 Apr 15 '16 at 02:15
  • 1
    @NickGinanto I do the same thing and it works great. Just every now and then I have to delete all those conflicts. It does not happen very often though, and the benefit of being able to stop coding at work and pick right up where I left off on my home PC is huge. Don't let anyone tell you otherwise. – Daniel Williams Jun 19 '19 at 15:17

4 Answers4

39

when dropbox finds conflicting files, it renames those to filename (conflicted copy) (as you might know). So you just have to rename again those files:

This might be a rather delicate exercise since you will be messing inside your git directory; better take a copy of your whole repository first. Now go into this directory

cd <repo>/.git/refs/heads

where you will find those badly renamed files. You'll have to check which one to keep (the normal or then conflicting copy), and remove the unwanted, renaming the conflicting copies as necessary. You'll have to do the same in the other directory:

<repo>/.git/refs/remotes

EDIT: each of the files you'll find just contains the hash of the commit they are pointing at. So if you want to check which one to keep; check which of the commits really exists, and where you want those references to point to.

michaelrbock
  • 1,160
  • 1
  • 11
  • 20
Chris Maes
  • 35,025
  • 12
  • 111
  • 136
  • 2
    Didn't realize these files were added by Google Drive/file syncing software. After removing the files with [Conflict] in the name I was good to go. – Charles Naccio Mar 09 '17 at 19:19
  • I could kiss you. Thanks. – Andrew Aug 08 '17 at 18:08
  • How to check which of the commits really exists ? – sparkle Aug 20 '19 at 21:39
  • If you don't have anything you care about in your gitignore, and the repo is stored elsewhere (e.g., GitHub) it may be easier to do one final push and then just remove the project folder altogether and re-clone. – BallpointBen Mar 25 '20 at 04:54
2

I got this warning possibly after updating my git version (ubuntu 15.04 to 15.10) and needed only to remove directories in .git/refs/remotes for old dangling remotes I no longer actually had configured.

Eric Woodruff
  • 6,380
  • 3
  • 36
  • 33
0

I pruned branches that were no longer on my remote by running

git remote prune origin

and that resolved the issue for me.

Vito Andolini
  • 425
  • 1
  • 5
  • 14
0

I had this warning:

warning: ignoring ref with broken name refs/heads/main (DropboxUser's conflicted copy 2023-08-22)

Since the name contained spaces, I had to wrap the name in parentheses before this command worked to fix the problem:

git update-ref -d "refs/heads/main (DropboxUser's conflicted copy 2023-08-22)"

I think in my case the problem was caused by 2 computers/Dropbox instances accessing the file a the same time.

soundflix
  • 928
  • 9
  • 22