0

I work on a repo with others, of which, we commit/pull from a bitbucket repo.

I needed to do a pull, but when I tried I got an error that a reference was broken in my IDE, as below:

enter image description here

In addition to this, in my IDE it seems to show that all the files are "new" and shows they need committing; when in actuality, there shouldn't be anything that needs to be committed.

I used the solution here, so I ran:

rm .git/refs/remotes/origin/2.0

After that I ran the git fsck command, but I got the below output:

error: refs/heads/2.0: invalid sha1 pointer 0000000000000000000000000000000000000000
error: invalid HEAD
error: bad ref for .git/logs/HEAD
error: bad ref for .git/logs/refs/heads/2.0
dangling blob 08f12165c07042e539c6ac88b365a96d35bef0a4
dangling blob 9a62767cc1463b4892d58f7d55a7c7c7d9e5d735
dangling blob 31737e10f9c73a51d0b30d0075f3a0d26cc7e9a0
dangling commit 609378008f36807d5c2d1062cfbedec0cc467943
dangling blob 969319da42df899791d3c85e3b3c8ad0742968b0
dangling blob b8a5369235ac3abd2628b7df85f0693126fe70c5
dangling blob f7e58848298e6c1efffa3ebc2dd9b18d1fbc1d09
dangling blob 0d2696322077d2483d9ee768269600e0010456c6
dangling blob 8a38dbed0980daed0323980af726de6bf66e8663
dangling blob 9238c0fad597aa49c1270b301dca8c6b9dfd3da0
dangling blob 166c6068c051c34b36cc44f00e9c36f7a6c22cda
dangling blob 263ce1d6f1cc89702562499e664cdc5d312cea3d
dangling blob 47fe36f31eea1bbad3d90d90637c5840718e1052
dangling blob b70eed498d36e1c577837be651cebb87bcad383c
dangling blob 861f5f6572390895b68134495c1c4ac7dea1a363

So I am unsure where to go from here?

Brett
  • 19,449
  • 54
  • 157
  • 290
  • 1
    If there is nothing to be committed, could you not just delete the repo and clone it again. Probably not the type of fix you are looking for, but when Occam's Razor works, why do anything differently – Jacob Jul 19 '21 at 19:09
  • @Jacob Possibly, but won't I lose all commit history - it's also connected to a secondary remote repo to make matters more complicated. – Brett Jul 20 '21 at 01:18
  • 1
    Because of the secondary repo, then no, don't go with my idea. However, for future reference in the case of just one remote repo, no you wouldn't lose your commit history by deleting the local repo. As long as all your commits are pushed, the remote repo would store the history. – Jacob Jul 20 '21 at 12:15

1 Answers1

0

Something is wrong with your refs, but you already know this. The good thing: your actual commit data seems to be fine, it is just some branch pointers and reflog interies which went amiss. You can safely delete them.

Create a backup of your worktree, now!

Since your HEAD ref is corrupt, you need to find a valid commit. Ideally one that is as close as possible to your working tree. If that's not possible, take the commit hash of your origin/master, origin/main, or any other development branch shared with your peers.

Then, make sure you have a valid HEAD ref again (this will lose uncommitted changes!):

git checkout -f -b fixing-things $origin_master_hash

Your local branch 2.0 points to an invalid ref (apparently the dummy 0000… commit). You can delete it too:

git update-ref 2.0

If that doesn't work, delete from the file system directly:

rm .git/refs/heads/2.0

Now expire the broken reflog entries or delete them, if expiring does not work:

git reflog delete HEAD
git reflog delete 2.0

(or delete: rm .git/logs/HEAD, rm .git/logs/refs/heads/2.0)

knittl
  • 246,190
  • 53
  • 318
  • 364
  • Do I need to do a checkout to master? When I try and do so it is telling me that I have uncommited changes with a file listing, but this is a smaller list then it is showing me elsewhere of apparent files with changes. – Brett Jul 19 '21 at 20:24
  • @Brett sorry, that was not very clever. I've changed the answer so that you create a new branch from your current commit. This doesn't require switching branches and avoids problems with uncommitted changes. – knittl Jul 19 '21 at 20:26
  • Haha ok, now a new error when trying to create the new branch. `fatal: You are on a branch yet to be born`. – Brett Jul 19 '21 at 20:49
  • Oh, right. Because your `HEAD` is broken. This is going to be trickier than I thought. Make a backup of your worktree _now_. Then we need to find a commit as close as possible to your now-lost checkout-tree – knittl Jul 19 '21 at 20:53
  • Do you mean to just make a manual physical backup of the files? – Brett Jul 19 '21 at 23:09
  • @Brett: yes. Create a zip/tar file of your directory, or create a copy with `cp -r`. You don't want to lose any uncommitted changes – knittl Jul 20 '21 at 04:52
  • Ok, I have done that. That won't affect other branches will it as they are checked out from the main repo? – Brett Jul 20 '21 at 06:13
  • It will not affect other branches. But I'm confused by what you mean with "as they are checked out from the main repo". For a single working directory, only a single branch can be checked out. – knittl Jul 20 '21 at 06:23
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/235088/discussion-between-knittl-and-brett). – knittl Jul 20 '21 at 06:23