Git: "Corrupt loose object"

Question

Whenever I pull from my remote, I get the following error about compression. When I run the manual compression, I get the same:

$ git gc
error: Could not read 3813783126d41a3200b35b6681357c213352ab31
fatal: bad tree object 3813783126d41a3200b35b6681357c213352ab31
error: failed to run repack

Does anyone know, what to do about that?

From cat-file I get this:

$ git cat-file -t 3813783126d41a3200b35b6681357c213352ab31
error: unable to find 3813783126d41a3200b35b6681357c213352ab31
fatal: git cat-file 3813783126d41a3200b35b6681357c213352ab31: bad file

And from git fsck I get this ( don't know if it's actually related):

$ git fsck
error: inflate: data stream error (invalid distance too far back)
error: corrupt loose object '45ba4ceb93bc812ef20a6630bb27e9e0b33a012a'
fatal: loose object 45ba4ceb93bc812ef20a6630bb27e9e0b33a012a (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted

Can anyone help me decipher this?

Have you tried looking at the latter object (45ba4ceb93bc812ef20a6630bb27e9e0b33a012a)? — Gintautas Miliauskas, Nov 23 '10 at 13:56
Thanks... but how do one "look" at an object? Still new to git :) — asgerhallas, Nov 23 '10 at 14:23
´git show´ gives me nothing more than ´git fsck´ already did unfortunately. — asgerhallas, Nov 26 '10 at 14:40
Can you add some comments, or edit, the accepted answer? I'm in the exact same situation, and the accepted answer doesn't seem to contain enough detail to "Just Work TM", but will instead force me to dive into the details myself. — ripper234, Feb 20 '12 at 21:37
`git cat-file -t ` will tell you the type. If not corrupted, you can then do `git cat-file ` to see the content (I used it for a `blob`, I guess it will also show you the contents of other types.) — Carl G, Jul 12 '12 at 14:45
In my case it was just a permission issue. I tried to pull again as root and it worked. — Ricardo Martins, Mar 13 '13 at 13:13
Related: http://stackoverflow.com/questions/801577/how-to-recover-git-objects-damaged-by-hard-disk-failure — Vadzim, Jul 10 '15 at 15:05
Linus Torvalds wrote the following helpful document about this error and how to manually reconstruct the blobs if you have the files: [**How to recover a corrupted blob object** Some tricks to reconstruct blob objects in order to fix a corrupted repository](http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/howto/recover-corrupted-blob-object.txt;h=323b513ed0e0ce8b749672f589a375073a050b97;hb=HEAD) — Uwe Kleine-König, May 19 '11 at 08:35

score 523 · Accepted Answer · edited Sep 22 '16 at 15:02

523

I had the same problem (don't know why).

This fix requires access to an uncorrupted remote copy of the repository, and will keep your locally working copy intact.

But it has some drawbacks:

You will lose the record of any commits that were not pushed, and will have to recommit them.
You will lose any stashes.

The fix

Execute these commands from the parent directory above your repo (replace 'foo' with the name of your project folder):

Create a backup of the corrupt directory:
cp -R foo foo-backup
Make a new clone of the remote repository to a new directory:
git clone git@www.mydomain.de:foo foo-newclone
Delete the corrupt .git subdirectory:
rm -rf foo/.git
Move the newly cloned .git subdirectory into foo:
mv foo-newclone/.git foo
Delete the rest of the temporary new clone:
rm -rf foo-newclone

On Windows you will need to use:

copy instead of cp -R
rmdir /S instead of rm -rf
move instead of mv

Now foo has its original .git subdirectory back, but all the local changes are still there. git status, commit, pull, push, etc. work again as they should.

edited Sep 22 '16 at 15:02

ANeves

6,219
3
39
63

answered Dec 17 '12 at 16:59

cubic lettuce

6,301
3
18
25

13

This method worked for me. However, I believe all unpushed commits were lost. Repo data was untouched. – wonton Feb 11 '13 at 23:46
38

Yes, unpushed commit information will get lost. But in common scenarios (no multiple local branches with unpushed changes in others than the current), all the most recent file modifications (inkl. deletions) are still on disc, thus, one can easily repeat any previous unpushed commits. Since I always push after any sequence of commits, I even did not ran into this trouble. – cubic lettuce Feb 20 '13 at 09:19
10

Simple and straightforward. This is, IMO, the most efficient solution if you don't understand everything about git and you don't want to fiddle with your repository. – Oliboy50 Jun 11 '14 at 12:54
Will this affect stashed changes? – Alex Wood Jul 29 '14 at 00:58
4

I think it would remove all stashes since they are stored under the .git subdirectory. – Anthony Elliott Jul 31 '14 at 16:25
5

In case there is submodules in the project, it's necessary to init them before retrieve the `.git` folder. – AdrieanKhisbe Aug 26 '14 at 07:59
1

btw, on windows where `cp` and `rm` are not available, I had success just using the Windows Explorer to delete and replace the .git subdirectory from the new clone. – parliament Jun 29 '15 at 06:35
1

In my case, I have used git svn before the problem occured. And after the fix, the git-svn-branch was lost. Probably, because it was only locally present for managing the svn repository synchronisation. Anyway, after going through your solution step-for-step, the problem with the corrupt file was solved and the git-svn-branch is gone. So, just for fun, I tried to copy the .git folder to the foo back again. And suprisingly the problem did not appear again AND I had the git-svn branch back. Thus, everything is fine now. Thank you. +1 – Dima Jun 17 '16 at 13:06
2

It solved the problem but I lost my important all other branches than master, so use very very carefully – Shirish Herwade Jun 29 '16 at 13:26
1

This should be the accepted answer. Easier than learning the internal workings of git. – earl3s Jul 11 '16 at 07:39
I agree @earl3s; this should be the accepted answer. My issue included me being on a feature branch (which _was_ synced with remote repository). So when got to step #6, I had a lot of modified files (because I was on master). I had to perform these additional commands: `git checkout -b loose-object-fix` / `git add --all` / `git commit -m "Loose object files"` / `git checkout `. I was then back where I was before the loose object situation. – Luc Jul 14 '16 at 05:19
1

I agree that this is the simplest answer, but you lose **anything** not stored in the remote repo. Stashes are mentioned, but you could conceivably have several purely-local branches. I think this is a big enough qualification that it should not be the recommended approach. However, I think the accepted answer should be updated to say "if you have nothing local, consider (this) answer". – claytond Feb 23 '17 at 17:07
It's work for me but my newly created file show blank.can i get back newly created file? – bipin patel Sep 08 '18 at 07:00
1

Do you mean by "newly created file" a file that was not yet added to git? If yes, then the above steps cannot delete its content. You will surely see in `foo-backup` from step 1 that the file was empty before. – cubic lettuce Sep 09 '18 at 16:28
This could lose all the work in the local `git reflog` that only exists on this local copy of the repository and nowhere else. – Darren Weber Apr 11 '19 at 19:24
occured for me after a power failure during a pull. Pretty obvious that was the cause for me. – nihilok Mar 02 '21 at 10:05
watch out! if there was a commit done from other computer, your local changes will be considered a new commit. – Art3mix May 28 '21 at 11:59
This worked for me. However, part of my repository was also corrupted, so I copied the whole newly cloned repository after step 4. – mtchuente Aug 01 '22 at 15:12

score 424 · Answer 2 · edited Aug 29 '21 at 14:44

424

Your best bet is probably to simply re-clone from the remote repository (i.e., GitHub or other). Unfortunately you will lose any unpushed commits and stashed changes, however your working copy should remain intact.

First make a backup copy of your local files. Then do this from the root of your working tree:

rm -fr .git
git init
git remote add origin [your-git-remote-url]
git fetch
git reset --mixed origin/master
git branch --set-upstream-to=origin/master master

Then commit any changed files as necessary.

edited Aug 29 '21 at 14:44

Peter Mortensen

30,738
21
105
131

answered Aug 14 '13 at 17:26

user1055643

4,931
1
15
3

19

IMHO this should be the accepted answer. Much easier than deleting the repo and re-cloning! :) Although you do lose any staged commits... – Nick Jan 22 '15 at 14:43
10

Obviously, if you were in a branch other than master when the corruption happened, replace `master` with your branch name. – Timothy Zorn Feb 09 '17 at 23:33
Mostly worked as is, but I was on another branch `working` when it corrupted and these steps didn't give me a local copy of any branch other than master (and yes I had tried to replace master above with `working` but that didn't work). Ended up doing the above steps with `master`, then stashing my changes and doing `checkout -b working origin/working` and popping the stash there. Seems to have worked - thanks! – fantabolous Dec 16 '17 at 05:13
1

My repository had a submodule that was not corrupt. This process left the repository and its submodule in a state where commands such as `git status` yielded `fatal: Not a git repository: submodules/my-sub/../../.git/modules/my-sub`. Deleting the submodule from the filesystem and restarting the process restored normalcy. Probably making sure there are no un-pushed changesets in submodules first is a good idea... – Steven Baldasty Feb 22 '18 at 20:43
7

I did this today and didn't lose uncommitted changes to the files :) (git 2.17.1) – Fábio Dias Jun 12 '18 at 18:03
This answer has helped me work out this problem so many (20+) times. Thank you man! – 0xInfection Nov 07 '18 at 09:07
This worked beautifully. I was expecting to lose my changes since last push but everything was as it should be after running these commands – Max Oct 23 '19 at 12:17
I'd replace the last command with - `git push --set-upstream origin master`. The original command didn't work for me – Meir Gabay Dec 29 '19 at 10:18
this answer helped me retrieve a huge amount of corrupt code – Shadab K Mar 25 '20 at 13:32
thank you so much, it helped me out just before a project presentation :') – HYAR7E Aug 11 '20 at 03:52
Best solution! Especially for people like me who don't bother much about branches. Tags will do. And for those who push new commits often. One commit got corrupted, the most recent one. A brownout during a push. Touch luck. This strategy helped me out. – Dimitri Mostrey Jul 13 '21 at 21:26
This method worked for me, everything was as it should be after running these commands. I think this should be the accepted answer. – Gustavo Martínez Oct 05 '21 at 08:48
2

If you see this message, you may need to change the `master` branch to the `main` branch. – CrowRish Jan 03 '22 at 00:31
this did not work for me, started getting persmission errors. I recloned the project and it works now – peterretief Mar 03 '23 at 08:52
I got error `fatal: refusing to merge unrelated histories` I copied the origin directory, cleaned the original directory, git init again and added the git directory as origin, pulled the git repo, copied back the local files from into this directory merging folders and replacing existing files. and it was all okay. – Irfan Ahmad Mar 27 '23 at 05:56

score 343 · Answer 3 · answered Oct 18 '16 at 02:20

Working on a VM, in my notebook, battery died, got this error;

error: object file .git/objects/ce/theRef is empty error: object file .git/objects/ce/theRef is empty fatal: loose object theRef (stored in .git/objects/ce/theRef) is corrupt

I managed to get the repo working again with only 2 commands and without losing my work (modified files/uncommitted changes)

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin

After that I ran a git status, the repo was fine and there were my changes (waiting to be committed, do it now..).

git version 1.9.1

Remember to backup all changes you remember, just in case this solution doesn't works and a more radical approach is needed.

You might need to run `git symbolic-ref HEAD refs/heads/master.` after the deleting the empty objects. — Stephan, Nov 19 '17 at 18:29

score 69 · Answer 4 · edited Mar 11 '20 at 08:48

69

Looks like you have a corrupt tree object. You will need to get that object from someone else. Hopefully they will have an uncorrupted version.

You could actually reconstruct it if you can't find a valid version from someone else by guessing at what files should be there. You may want to see if the dates & times of the objects match up to it. Those could be the related blobs. You could infer the structure of the tree object from those objects.

Take a look at Scott Chacon's Git Screencasts regarding git internals. This will show you how git works under the hood and how to go about doing this detective work if you are really stuck and can't get that object from someone else.

edited Mar 11 '20 at 08:48

Daniel B.

1,254
1
16
35

answered Nov 24 '10 at 02:37

Adam Dymitruk

124,556
26
146
141

to be able to reconstruct the objects, you need to use some plumbing commands in git. – Adam Dymitruk Nov 25 '10 at 01:39
Another note... can you (or anyone) tell me what a loose object actually is? The object does exist as a file in my copy of the repository, but in no one elses copy. So I can not get it from somewhere else it seems. But it does not seem to hurt anyone, that they donøt have it :-S – asgerhallas Nov 26 '10 at 14:44
2

it may be stored in a pack file. This is the way git compresses storage of objects by storing deltas. Loose objects are ones that are not in a package yet. Google for pack files, index files in git and you should be able to dive in as deep as you need. – Adam Dymitruk Nov 26 '10 at 18:04
2

Could you provide a link in your answer towards Chacon's Git screencasts? – Ehtesh Choudhury Apr 18 '12 at 22:41
1

`git cat-file -t ` will tell you the type. If not corrupted, you can then do `git cat-file ` to see the content (I used it for a `blob`, I guess it will also show you the contents of other types.) – Carl G Jul 12 '12 at 14:46
1

Also [this post](http://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/howto/recover-corrupted-blob-object.txt) from Linus describes the process for recovering a `blob`. When I followed these instructions, though, `git status` responsed `fatal: unable to read ` even though I had successfully ran `git hash-object -w ` (probably because, per his instructions, I had moved that object file away. Returning it just gave me the same `corrupt loose object` error.) – Carl G Jul 12 '12 at 15:03
3

And now repeat in English please – Mehdi Mar 23 '16 at 14:01
@CarlG This probably means that when you `git hash-object`ed the file, it wasn't exactly the one you lost.If it was the same, the it would write a new object in plcae of the object you had moved away. You must have been able to see whether it matched by the checksum printed by the command. In general, I believe the instructions from Linus the best answer here, because they work in different situations (whatever the cause of loosing the object is and independently of available backups) and explain an important thing for fast recovery: a way to find the tree that refers to this object & its name – imz -- Ivan Zakharyaschev Feb 27 '20 at 03:59
Updated Linus post [link](https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/howto/recover-corrupted-blob-object.txt?id=HEAD) (and [backup](https://github.com/git/git/blob/master/Documentation/howto/recover-corrupted-blob-object.txt)) – Carl G Feb 27 '20 at 08:59

score 55 · Answer 5 · edited Aug 29 '21 at 14:51

My computer crashed while I was writing a commit message. After rebooting, the working tree was as I had left it and I was able to successfully commit my changes.

However, when I tried to run git status I got

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

Unlike most of the other answers, I wasn't trying to recover any data. I just needed Git to stop complaining about the empty object file.

Overview

The "object file" is Git's hashed representation of a real file that you care about. Git thinks it should have a hashed version of some/file.whatever stored in .git/object/xx/12345, and fixing the error turned out to be mostly a matter of figuring out which file the "loose object" was supposed to represent.

Details

Possible options seemed to be

Delete the empty file
Get the file into a state acceptable to Git

Approach 1: Remove the object file

The first thing I tried was just moving the object file

mv .git/objects/xx/12345 ..

That didn't work - Git began complaining about a broken link. On to Approach 2.

Approach 2: Fix the file

Linus Torvalds has a great writeup of how to recover an object file that solved the problem for me. Key steps are summarized here.

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345    your_file.whatever

This tells you what file the empty object is supposed to be a hash of. Now you can repair it.

$> git hash-object -w path/to/your_file.whatever

After doing this I checked .git/objects/xx/12345, it was no longer empty, and Git stopped complaining.

I was in a situation where I did not have any remote or backup of my repo, and where the corrupted object was added near the initial commit, probably corrupting the entire tree anyway. I had my own way trying to recreate the object in a different repo, but this answer achieves the same result with more finesse. — Estecka, Dec 14 '19 at 15:31
Doesn't work for me. I get `error: object file .git/objects/af/c1e62b3ff4f76d034551fa5c6131635a83434f is empty` but these files are missing and `git fsck` does not list any broken links. — reinierpost, Sep 01 '21 at 11:22
Delete the corrupted file manually and then do git pull. It will fix the issue. — Iftikhar Ali Ansari, Sep 13 '21 at 10:07
Delete the corrupted file manually and then do git pull does not work. Instead, it throughs an error message "Could not read . — spadelives, May 10 '22 at 03:56

score 18 · Answer 6 · edited Aug 29 '21 at 14:52

18

A garbage collection fixed my problem:

git gc --aggressive --prune=now

It takes a while to complete, but every loose object and/or corrupted index was fixed.

edited Aug 29 '21 at 14:52

Peter Mortensen

30,738
21
105
131

answered Oct 26 '15 at 08:23

Jago

2,751
4
27
41

2

This is good solution. Worked for me. My system shutdown accidentally. However, this one command saved me from cloning and all those heavy tasks. Thanks Jago. – Mukesh Kumar Aug 16 '17 at 13:05
12

"failed to run reflog" – Vladimir Brasil Feb 13 '20 at 12:29
2

From [another question](https://stackoverflow.com/questions/1904860/how-to-remove-unreferenced-blobs-from-my-git-repository/29203553#29203553): ***"Only*** *using `git gc --prune=now` will not work since those commits are still referenced in the reflog. Therefore, clearing the reflog is mandatory."* – Peter Mortensen Aug 29 '21 at 18:48

score 17 · Answer 7 · answered Sep 29 '11 at 09:59

17

Try

git stash

This worked for me. It stashes anything you haven't committed and that got around the problem.

answered Sep 29 '11 at 09:59

Arthur

1,332
2
19
39

1

**Weird!?!** Came across this error this morning. Had committed yesterday, so no uncommited changed. Did the following: `git stash` _... fatal: Unable to create '/home//.git/index.lock': Input/output error_ `touch .git/a` _touch: cannot touch ‘.git/a’: Input/output error_ `sudo touch /home/guest/.git/a` *NO ERROR* `git stash` _No local changes to save_ `git status` _... nothing to commit, working directory clean_ – go2null Nov 06 '15 at 16:02
2

@go2null I'm a bit late on this, but Input/Output errors generally mean hard drive issues. Although I'm sure you've figured this out by now. – arleslie Mar 05 '16 at 06:14
"Cannot save the current index state" – Vladimir Brasil Feb 13 '20 at 12:29

score 9 · Answer 8 · answered Oct 18 '18 at 20:21

9

simply running a git prune fixed this issue for me

answered Oct 18 '18 at 20:21

Tyler Gauch

160
1
6

This worked for me and seems like the easiest solution. Not sure why this answer didn't get more votes. The only drawback is that the next `git pull` takes a bit longer than usual, I guess because it's replacing some removed objects or something. – steev May 30 '19 at 19:05
6

The reason might be that git prune doesn't solve the problem at all. – user3072843 Aug 03 '19 at 11:24

score 6 · Answer 9 · answered Apr 12 '20 at 06:01

6

I encountered this once my system crashed. What I did is this:

(Please note your corrupt commits are lost, but changes are retained. You might have to recreate those commits at the end of this procedure)

Backup your code.
Go to your working directory and delete the .git folder.
Now clone the remote in another location and copy the .git folder in it.
Paste it in your working directory.
Commit as you wanted.

answered Apr 12 '20 at 06:01

Wajahath

2,827
2
28
37

1

This has saved my life. Thank you so much friend. But be aware, you will be getting new changes with this steps. So lookout for them and then go for commit and push. – Saurabh Ghewari Feb 02 '21 at 09:21

score 6 · Answer 10 · answered Oct 23 '22 at 05:55

6

Have the same issue after my linux mint crash, and I press power button to shutdown my laptop, that's why my .git is corrupt

find .git/objects/ -empty -delete

After that, I get error fatal: Bad object head. I just Reinitialized my git

git init

And fetch from remote repo

git fetch

To check your git, use

git status

And it's work again. I don't lose my local changes, so I can commit without rewriting code

answered Oct 23 '22 at 05:55

Sasmita Novitasari

191
3
7

thank you are was expecting a struggle but it was simple to get back my work – peterretief Mar 03 '23 at 08:10

score 5 · Answer 11 · answered Jan 04 '15 at 19:43

I just experienced this - my machine crashed whilst writing to the Git repo, and it became corrupted. I fixed it as follows.

I started with looking at how many commits I had not pushed to the remote repo, thus:

gitk &

If you don't use this tool it is very handy - available on all operating systems as far as I know. This indicated that my remote was missing two commits. I therefore clicked on the label indicating the latest remote commit (usually this will be /remotes/origin/master) to get the hash (the hash is 40 chars long, but for brevity I am using 10 here - this usually works anyway).

Here it is:

14c0fcc9b3

I then click on the following commit (i.e. the first one that the remote does not have) and get the hash there:

04d44c3298

I then use both of these to make a patch for this commit:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

I then did likewise with the other missing commit, i.e. I used the hash of the commit before and the hash of the commit itself:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

I then moved to a new directory, cloned the repo from the remote:

git clone git@github.com:username/repo.git

I then moved the patch files into the new folder, and applied them and committed them with their exact commit messages (these can be pasted from git log or the gitk window):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

This restored things for me (and note there's probably a faster way to do it for a large number of commits). However I was keen to see if the tree in the corrupted repo can be repaired, and the answer is it can. With a repaired repo available as above, run this command in the broken folder:

git fsck

You will get something like this:

error: object file .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty
error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d
error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

To do the repair, I would do this in the broken folder:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d
cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

i.e. remove the corrupted file and replace it with a good one. You may have to do this several times. Finally there will be a point where you can run fsck without errors. You will probably have "dangling commit" and "dangling blob" lines in the report, these are a consequence of your rebases and amends in this folder, and are OK. The garbage collector will remove them in due course.

Thus (at least in my case) a corrupted tree does not mean unpushed commits are lost.

score 5 · Answer 12 · answered Apr 30 '21 at 18:36

5

The solution offered by Felipe Pereira (above) in addition to Stephan's comment to that answer with the name of the branch I was on when the objects got corrupted is what worked for me.

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin
git symbolic-ref HEAD refs/heads/${BRANCH_NAME}

answered Apr 30 '21 at 18:36

geogeo

124
2
4

The first line throws a "Find: Parameter not correct" error. – spadelives May 10 '22 at 04:00
1

@spadelives - looks like you’re probably attempting to execute the command in Windows cmd.exe or Powershell. My example is for a bash shell, where the `find` command is for searching for files in a directory structure vs in the Window’s shells where `find` is for searching for a string within text or files. – geogeo May 11 '22 at 14:04

score 4 · Answer 13 · edited Aug 29 '21 at 14:46

4

The answer of user1055643 is missing the last step:

rm -fr .git
git init
git remote add origin your-git-remote-url
git fetch
git reset --hard origin/master
git branch --set-upstream-to=origin/master master

edited Aug 29 '21 at 14:46

Peter Mortensen

30,738
21
105
131

answered Oct 02 '14 at 01:21

Ertuğrul Altınboğa

2,187
4
17
25

is --set-upstream-to a valid argument? I don't think so! – Sharif Mamun Nov 30 '14 at 21:36
2

git branch (--set-upstream-to= | -u ) [] – Ertuğrul Altınboğa Jan 30 '15 at 05:42
If you remove `.git` and copy from the cloned project, repo will work, but no local branches, nor stashes will be preserved. – Vladimir Vukanac Dec 29 '17 at 09:33

score 4 · Answer 14 · answered May 27 '16 at 07:28

To me this happened due to a power failure while doing a git push.

The messages looked like this:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

I tried things like git fsck but that didn't help. Since the crash happened during a git push, it obviously happened during rewrite on the client side which happens after the server is updated. I looked around and figured that c2388 in my case was a commit object, because it was referred to by entries in .git/refs. So I knew that I would be able to find c2388 when I look at the history (through a web interface or second clone).

On the second clone I did a git log -n 2 c2388 to identify the predecessor of c2388. Then I manually modified .git/refs/heads/master and .git/refs/remotes/origin/master to be the predecessor of c2388 instead of c2388. Then I could do a git fetch. The git fetch failed a few times for conflicts on empty objects. I removed each of these empty objects until git fetch succeeded. That has healed the repository.

score 3 · Answer 15 · answered Apr 16 '14 at 08:40

3

Runnning git stash; git stash pop fixed my problem

answered Apr 16 '14 at 08:40

Simonluca Landi

931
8
21

score 3 · Answer 16 · edited May 23 '17 at 12:34

I followed many of the other steps here; Linus' description of how to look at the git tree/objects and find what's missing was especially helpful. git-git recover corrupted blob

But in the end, for me, I had loose/corrupt tree objects caused by a partial disk failure, and tree objects are not so easily recovered/not covered by that doc.

In the end, I moved the conflicting objects/<ha>/<hash> out of the way, and used git unpack-objects with a pack file from a reasonably up to date clone. It was able to restore the missing tree objects.

Still left me with a lot of dangling blobs, which can be a side effect of unpacking previously archived stuff, and addressed in other questions here

This page explains how to use `git unpack-objects` well, and it worked nicely for me. https://git.seveas.net/repairing-and-recovering-broken-git-repositories.html — remcycles, Feb 23 '21 at 04:50

score 3 · Answer 17 · answered Jul 21 '15 at 15:20

I was getting a corrupt loose object error as well.

./objects/x/x

I successfully fixed it by going into the directory of the corrupt object. I saw that the users assigned to that object was not my git user's. I don't know how it happened, but I ran a chown git:git on that file and then it worked again.

This may be a potential fix for some peoples' issues but not necessary all of them.

score 1 · Answer 18 · answered Feb 13 '15 at 10:42

We just had the case here. It happened that the problem was the ownership of the corrupt file was root instead of our normal user. This was caused by a commit done on the server after someone has done a "sudo su --".

First, identify your corrupt file with:

$> git fsck --full

You should receive a answer like this one:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

Go in the folder where the corrupt file is and do a:

$> ls -la

Check the ownership of the corrupt file. If that's different, just go back to the root of your repo and do a:

$> sudo chown -R YOURCORRECTUSER:www-data .git/

Hope it helps!

score 1 · Answer 19 · answered Mar 29 '17 at 12:27

I solved this way: I decided to simply copy the uncorrupted object file from the backup's clone to my original repository. This worked just as well. (By the way: If you can't find the object in .git/objects/ by its name, it probably has been [packed][pack] to conserve space.)

score 1 · Answer 20 · answered Jan 26 '22 at 09:47

This seems to be an issue with Dropbox or symlinking folders out of Dropbox for me. Probably the same for any of the other similar services. When I go to git push I'd get the Corrupt loose object error. For me, on macOS Big Sur, the fix was simply to make a recursive copy of the repo to a directory outside of Dropbox. I believe this caused Dropbox to pull the live files for the broken dynamic references. After the copy I was immediately able to git push without error.

score 1 · Answer 21 · answered May 01 '22 at 14:05

I have had the same issue before. I simply get passed it by removing the object file from the .git/objects directory.

For this error below.

$ git fsck
error: inflate: data stream error (invalid distance too far back)
error: corrupt loose object '45ba4ceb93bc812ef20a6630bb27e9e0b33a012a'
fatal: loose object 45ba4ceb93bc812ef20a6630bb27e9e0b33a012a (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted

Solution:

Go to your top directory and unhide the .git folder

On windows, you can do this by running this command on cmd: attrib +s +h .git

Then go to .git/objects folder
As mentioned on the error message above (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted you can see that the object is found on a director called "45". Therefore, go to the directory .git/objects/45/
Finally find the object named ba4ceb93bc812ef20a6630bb27e9e0b33a012a and delete it.

Now, you can go ahead and check with git status or git add . your change and proceed.

score 0 · Answer 22 · edited Aug 29 '21 at 14:40

0

I got this error after my (Windows) machine decided to reboot itself.

Thankfully my remote repository was up to date, so I just did a fresh Git clone...

edited Aug 29 '21 at 14:40

Peter Mortensen

30,738
21
105
131

answered May 21 '12 at 12:10

Dean Rather

31,756
15
66
72

score 0 · Answer 23 · answered Jun 21 '13 at 18:58

I had this same problem in my bare remote git repo. After much troubleshooting, I figured out one of my coworkers had made a commit in which some files in .git/objects had permissions of 440 (r--r-----) instead of 444 (r--r--r--). After asking the coworker to change the permissions with "chmod 444 -R objects" inside the bare git repo, the problem was fixed.

score 0 · Answer 24 · answered Nov 26 '15 at 01:37

I just had a problem like this. My particular problem was caused by a system crash that corrupted the most recent commit (and hence also the master branch). I hadn't pushed, and wanted to re-make that commit. In my particular case, I was able to deal with it like this:

Make a backup of .git/: rsync -a .git/ git-bak/
Check .git/logs/HEAD, and find the last line with a valid commit ID. For me, this was the second most recent commit. This was good, because I still had the working directory versions of the file, and so the every version I wanted.
Make a branch at that commit: git branch temp <commit-id>
re-do the broken commit with the files in the working directory.
git reset master temp to move the master branch to the new commit you made in step 2.
git checkout master and check that it looks right with git log.
git branch -d temp.
git fsck --full, and it should now be safe to delete any corrupted objects that fsck finds.
If it all looks good, try pushing. If that works,

That worked for for me. I suspect that this is a reasonably common scenario, since the most recent commit is the most likely one to be corrupted, but if you lose one further back, you can probably still use a method like this, with careful use of git cherrypick, and the reflog in .git/logs/HEAD.

score 0 · Answer 25 · answered Jan 30 '18 at 17:23

0

When I had this issue I backed up my recent changes (as I knew what I had changed) then deleted that file it was complaining about in .git/location. Then I did a git pull. Take care though, this might not work for you.

answered Jan 30 '18 at 17:23

gareth

199
1
3

score 0 · Answer 26 · answered Dec 21 '20 at 10:36

Create a backup and clone the repository into a fresh directory

cp -R foo foo-backup
git clone git@url:foo foo-new

(optional) If you are working on a different branch than master, switch it.

cd foo-new
git checkout -b branch-name origin/branch-name

Sync changes excluding the .git directory

rsync -aP --exclude=.git foo-backup/ foo-new

score 0 · Answer 27 · answered Mar 05 '21 at 10:50

This problem usually occures when using various git clients with different versions on the same git checkout. Think of:

Command line
IDE build-in git
Inside docker / vm container
GIT gui tool

Make sure you push with the same client that created the commits.

score 0 · Answer 28 · answered Mar 25 '21 at 10:14

What I did not to lose other unpushed branches: A reference to the broken object should be in refs/heads/<current_branch>. If you go to .git\logs\refs\heads\<current_branch> you can see that the last commit has the exactly same value. I copied the one from the previous commit to the first file and it solved the problem.

score 0 · Answer 29 · answered Feb 08 '22 at 16:13

I had a similar issue on a Windows 10 computer with onedrive backing up my documents folder where I have my git repositories.

Looking at the object in the git object directory I did not see a green checkmark but the blue sync icon for that file. All other object files appeared to have the green checkmark. Playing around, trying things, I tried selecting the option always keep this folder on this device but got an error: error 0x80071129 the tag present in the reparse point buffer is invalid.

This link (https://answers.microsoft.com/en-us/msoffice/forum/all/error-0x80071129-the-tag-present-in-the-reparse/b8011cee-98c5-4c33-ba99-d0eec7c535a0) suggests to run chkdsk /r /f as an admin to fix the issue (have to reboot computer). I did that and it fixed my issue.

score 0 · Answer 30 · answered Dec 03 '22 at 00:35

I had the exact same error and managed to get my repo back without losing my changes.

I do not know if it could work for others as corruption reason can be multiple, but it's worth trying

I:

Made several backups of the corrupt git repository just in case
Cloned the lasted pushed version from the remote repository
Copied all the files from the corrupt .git folder EXCEPT all files related to HEAD, FETCH_HEAD, ORG_HEAD etc ... the most important are the refs, obj, and index
Ended up with a valid history, but corrupt index, applied the solution from this post How to resolve "Error: bad index – Fatal: index file corrupt" when using Git

And my repository was back working ...

To make sure I did not push anything wrong, I cloned again from the remote, checked-out the changes I wanted to save from the restored repository, and comited them fresh.

score 0 · Answer 31 · answered Mar 13 '23 at 23:03

0

The way I fixed it was to find the .git file in the folder and then try to resubmit everything in GitHub. Because I was OK with what I had on the local computer, it was OK for me to have the old .git file removed was OK. However, having it backed out somewhere is a much better idea because, as someone mentioned, it could cause side effects, so please try other methods first. But this worked for me.

git remote add <name of repo such as main> <URL>
git commit -m"First commit."
git push --set-upstream <name of repo such as main> <name of repo such as main>

answered Mar 13 '23 at 23:03

Emmanuel Kofy Agyapong

17
1
8

1

Welcome to stackoverflow! While It's great to add new solutions to existing questions, this particular suggestion (removing the local .git folder and use a backup) has already been made multiple times and explained in more detail in other answers. – ChrisB Mar 17 '23 at 17:09
@ChrisB, my apology. I fixed it while looking for a solution; however, when I read from the best solution that the problem was a local .git file, I understood that I had encountered similar issues in the past, so I went ahead and fixed it the way I knew how. Unfortunately, I did not read the rest of the comments, so I did not realize that others suggested the same solution as mine, so I apologize. – Emmanuel Kofy Agyapong Mar 17 '23 at 18:06

score 0 · Answer 32 · answered Mar 27 '23 at 16:18

In my case, the problem was that my terminal/laptop had crashed in the middle of checking out a branch and something corrupted just that branch. I couldn't git log/status/branch/etc. on that branch.

Most of the other answers here suggest removing the .git directory and recloning the repo from the remote, but this is a very destructive action. Before doing that, try instead resetting the problematic branch to your master/main/whatever branch (or, if master/main/etc. is your corrupted branch, try resetting it to some other ref whose name you remember):

git reset --hard master

Or try just checking out that branch.

This got me out of the corrupted branch state, allowing me to see my logs/stashes/branches/statuses/etc. Granted, I lost all of my commits on that branch, but this is much better than losing all work on all branches and having to reclone the repo.

score -1 · Answer 33 · answered Jun 21 '21 at 16:04

You don't need to clone and you don't need to lose your uncommited changes. Just remove .git folder with git rm -rf .git/ and then restore the git folder by initiating a new repo, setting remote and resetting head. I have added instructions for restoring removed git folder here:

https://stackoverflow.com/a/67610397/7584643

score -8 · Answer 34 · answered May 25 '16 at 07:13

-8

Just remove .git folder and add it again. This simple solution worked for me.

answered May 25 '16 at 07:13

Ovidiu Matan

5

3

This will nuke your local repository ... , might have rather unwanted side-effects :) Please edit your proposal and add that warning. – Felix Jan 26 '17 at 07:36
1

If you remove `.git`, and copy from the clonned project, repo will work, but no local branches, nor stashes will be preserved. Also, a friendly suggestion, delete your answer completely in order to stop receiving down-votes. – Vladimir Vukanac Dec 29 '17 at 09:30
1

whoa nelly... talk about using a bazooka for a tweezers job. – Tuncay Göncüoğlu Aug 27 '18 at 14:24
This is basically the same answer as https://stackoverflow.com/a/13918515/594765 , just not as detailed. – JBoy Jul 13 '20 at 11:25

Git: "Corrupt loose object"

34 Answers34

The fix

Overview

Details

Approach 1: Remove the object file

Approach 2: Fix the file

Linked

Related