How can I fix a corrupted Git repository?

As an alternative to Todd's last option (Full Restores and Re-Initialization), if only the local repository is corrupted, and you know the URL to the remote, you can use this to reset your .git to match the remote (replacing ${url} with the remote URL):

mv -v .git .git_old && # Remove old Git files git init && # Initialise new repository git remote add origin "${url}" && # Link to old repository git fetch && # Get old history # Note that some repositories use 'master' in place of 'main'. Change the following line if your remote uses 'master'. git reset origin/main --mixed # Force update to old history. 

This leaves your working tree intact, and only affects Git's bookkeeping.

I also recently made a Bash script for this very purpose (Appendix A), which wraps a bit of safety around this operation.

Note:

• If your repository has submodules, this process will mess them up somehow, and the only solution I've found so far is deleting them and then using git submodule update --init (or recloning the repository, but that seems too drastic).
• This tries to determine the correct choice between 'main' and 'master' depending on local configuration settings, however there may be some issues if used on a repository that uses 'master', on a machine that has 'main' as the default branch.
• This uses wget to check that the url is reachable before doing anything. This is not necessarily the best operation to determine that a site is reachable, and if you haven't got wget available, this can likely be replaced with ping -c 1 "${url_base}" (linux), ping -n 1 "${url_base}" (windows), or curl -Is "${url_base}"

Appendix A - Full script

Also published as a gist, though it is now out of date.

#!/bin/bash # Usage: fix-git [REMOTE-URL] # Must be run from the root directory of the repository. # If a remote is not supplied, it will be read from .git/config # # For when you have a corrupted local repo, but a trusted remote. # This script replaces all your history with that of the remote. # If there is a .git, it is backed up as .git_old, removing the last backup. # This does not affect your working tree. # # This does not currently work with submodules! # This will abort if a suspected submodule is found. # You will have to delete them first # and re-clone them after (with `git submodule update --init`) # # Error codes: # 1: If a URL is not supplied, and one cannot be read from .git/config # 4: If the URL cannot be reached # 5: If a Git submodule is detected if [[ "$(find -name .git -not -path ./.git | wc -l)" -gt 0 ]] ; then echo "It looks like this repo uses submodules" >&2 echo "You will need to remove them before this script can safely execute" >&2 echo "Then use \`git submodule update --init\` to re-clone them" >&2 exit 5 fi if [[ $# -ge 1 ]] ; then url="$1" else if ! url="$(git config --local --get remote.origin.url)" ; then echo "Unable to find remote 'origin': missing in '.git/config'" >&2 exit 1 fi fi if ! branch_default="$(git config --get init.defaultBranch)" ; then # if the defaultBranch config option isn't present, then it's likely an old version of git that uses "master" by default branch_default="master" fi url_base="$(echo "${url}" | sed -E 's;^([^/]*://)?([^/]*)(/.*)?$;\2;')" echo "Attempting to access ${url_base} before continuing" if ! wget -p "${url_base}" -O /dev/null -q --dns-timeout=5 --connect-timeout=5 ; then echo "Unable to reach ${url_base}: Aborting before any damage is done" >&2 exit 4 fi echo echo "This operation will replace the local repo with the remote at:" echo "${url}" echo echo "This will completely rewrite history," echo "but will leave your working tree intact" echo -n "Are you sure? (y/N): " read confirm if ! [ -t 0 ] ; # i'm open in a pipe then # print the piped input echo "${confirm}" fi if echo "${confirm}"|grep -Eq "[Yy]+[EeSs]*" ; # it looks like a yes then if [[ -e .git ]] ; then # remove old backup rm -vrf .git_old | tail -n 1 && # backup .git iff it exists mv -v .git .git_old fi && git init && git remote add origin "${url}" && git config --local --get remote.origin.url | sed 's/^/Added remote origin at /' && git fetch && git reset "origin/${branch_default}" --mixed else echo "Aborting without doing anything" fi 

TL;DR

Git doesn't really store history the way you think it does. It calculates history at run-time based on an ancestor chain. If your ancestry is missing blobs, trees, or commits then you may not be able to fully recover your history.

Restore Missing Objects from Backups

The first thing you can try is to restore the missing items from backup. For example, see if you have a backup of the commit stored as .git/objects/98/4c11abfc9c2839b386f29c574d9e03383fa589. If so you can restore it.

You may also want to look into git-verify-pack and git-unpack-objects in the event that the commit has already been packed up and you want to return it to a loose object for the purposes of repository surgery.

Surgical Resection

If you can't replace the missing items from a backup, you may be able to excise the missing history. For example, you might examine your history or reflog to find an ancestor of commit 984c11abfc9c2839b386f29c574d9e03383fa589. If you find one intact, then:

1. Copy your Git working directory to a temporary directory somewhere.
2. Do a hard reset to the uncorrupted commit.
3. Copy your current files back into the Git work tree, but make sure you don't copy the .git folder back!
4. Commit the current work tree, and do your best to treat it as a squashed commit of all the missing history.

If it works, you will of course lose the intervening history. At this point, if you have a working history log, then it's a good idea to prune your history and reflogs of all unreachable commits and objects.

Full Restores and Re-Initialization

If your repository is still broken, then hopefully you have an uncorrupted backup or clone you can restore from. If not, but your current working directory contains valid files, then you can always re-initialize Git. For example:

rm -rf .git git init git add . git commit -m 'Re-initialize repository without old history.' 

It's drastic, but it may be your only option if your repository history is truly unrecoverable. YMMV.

I experienced similar issues using Git version 2.7.1 under Ubuntu 18.04.3 (Bionic Beaver) lately. Here is how I did:

sudo apt install git-repair git-repair # Fix a broken Git repository or git-repair --force # Force repair, even if data is lost git fsck # To verify it was fixed 

Most of the time the recovery process was successful.

Before trying any of the fixes described on this page, I would advise to make a copy of your repository and work on this copy only. Then at the end if you can fix it, compare it with the original to ensure you did not lose any file in the repair process.

Another alternative which worked for me was to reset the Git head and index to its previous state using:

git reset --keep

You can also do the same manually by opening the Git GUI and selecting each "Staged changes" and click on "Unstage the change". When everything is unstaged, you should now be able to compress your database, check your database and commit.

I also tried the following commands, but they did not work for me. But they might for you depending on the exact issue you have:

git reset --mixed git fsck --full git gc --auto git prune --expire now git reflog --all 

Finally, to avoid this problem of synchronization damaging your Git index (which can happen with Dropbox, SpiderOak, or any other cloud disk), you can do the following:

1. Convert your .git folder into a single "bundle" Git file by using: git bundle create my_repo.git --all, then it should work just the same as before, but since everything is in a single file you won't risk the synchronization damaging your git repo any more.
2. Disable instantaneous synchronization: SpiderOak allows you to set the scheduling for checking changes to "automatic" (which means that it is as soon as possible, being monitoring file changes thanks to the OS notifications). This is bad, because it will start to upload changes as soon as you are doing a change, and then download the change, so it might erase the latest changes you were just doing. A solution to fix this issue is to set the changes monitoring delay to 5 minutes or more. This also fixes issues with instant saving note taking applications (such as Notepad++).

If you have a remote configured and you have / don't care about losing some unpushed code, you can do:

git fetch && git reset --hard 

I tried moving away the object files with 0 bytes and fetching them again from the remote, and it worked:

find . -type f -size 0 -exec mv {} /tmp \; git fetch 

It fetched the missing objects from the remote and allowed me to continue working without reinitializing the whole repository.

Here's a script (Bash) to automate the first solution by @CodeGnome to restore from a backup (run from the top level of the corrupted repository). The backup doesn't need to be complete; it only needs to have the missing objects.

git fsck 2>&1 | grep -e missing -e invalid | awk '{print $NF}' | sort -u | while read entry; do mkdir -p .git/objects/${entry:0:2} cp ${BACKUP}/objects/${entry:0:2}/${entry:2} .git/objects/${entry:0:2}/${entry:2} done 

git-repair (sudo apt install git-repair) with a few additional commands worked for me:

0. Create a backup copy of your corrupted repository.

1. Delete broken references:
   find .git/refs -size 0 -delete -print

2. Repair repository from remote(s):
   git-repair --force

3. Clean up dangling commits:
   git gc --prune=now

4. Fetch the latest state from remote:
   git fetch

Optionally switch to master and reset it to origin/master:
git checkout master
git reset --hard origin/master

Verify with git fsck:
git fsck

I created a new clone of the repository in another folder, imported the blobs from it.

In the original repo (make a backup first) I ran:

git reset --hard origin/main # DESTRUCTIVE - reset index to a known good state git unpack-objects < /path/to/new/clone/.git/objects/pack/<hash>.pack git fsck --full | grep -v dangling 

All was ok after that :)

If you are desperate you can try this:

git clone ssh://[email protected]/path/to/project destination --depth=1 

It will get your data, but you'll lose the history. I went with trial and error on my repo and --depth=10 worked, but --depth=50 gave me failure.

In my case, I was creating the repository from source code already in my pc and that error appeared. I deleted the .git folder and did everything again and it worked :)

I was facing the same issue, so I replaced the ".git" folder with a backed up version and it still wasn't working because the .gitconfig file was corrupted. The BSoD on my laptop corrupted it. I replaced it with the following code and Sourcetree restored all my repositories.

[user] name = *your username* email = *your email address* [core] autocrlf = true excludesfile = C:\\Users\\*user name*\\Documents\\gitignore_global.txt 

I don't know if this will help anybody, but this is just another solution that worked for me.

While my other answer here worked for me, another option to try:

• Create a fresh clone of the remote
• Add the fresh clone as a git alternate
• Run git fsck again with all the objects present via the alternate

If nothing above works, here is a report that modifying git with disabled checks worked for me very well. I just fixed with it an "irrecoverable" repo.

The essence:

The git binary objects (inside .git/objects) are just gzip-ped blobs, packed together in a binary data format. In most cases, if these files are damaged, you could get a very well working partial recovery - if git would support it. It has various checks (mostly: object file can not be opened, or unzipping the blob results error) it stops processing with a fatal error.

It requires a little bit of C skill, at least on the level that you can patch and recompile the git from source. What you need to modify, that is always the same: git somewhere stops processing with a fatal error, so you comment it out and substitute it with an empty mock. After that, a /your/patched/git gc --aggressive --prune=now (common super-agressive repacker) fixes what it should be fixed. For example, the patch below can fix a git repo where some object files are damaged. Of course, the recovery is only partial: files in the damaged objects are lost, even retroactively.

This might be the reason, why the git development does not implement such minor, but extremely useful improvement. I think, the required patch size would be likely below 100 lines.

Further developing the idea, probably also a git fork could be created, which can recover such damaged repos.

diff -urNw orig/sha1-file.c patched/sha1-file.c --- orig/sha1-file.c 2021-03-08 21:36:01.000000000 +0100 +++ patched/sha1-file.c 2021-08-19 18:32:44.019115545 +0200 @@ -1285,8 +1285,16 @@ else if (stream->avail_in) error(_("garbage at end of loose object '%s'"), oid_to_hex(oid)); + + error("error ignored"); + + /* free(buf); return NULL; + */ + + status = Z_OK; + return buf; } /* @@ -1656,7 +1664,7 @@ oid_to_hex(repl), oid_to_hex(oid)); if (!stat_loose_object(r, repl, &st, &path)) - die(_("loose object %s (stored in %s) is corrupt"), + error(_("loose object %s (stored in %s) is corrupt"), oid_to_hex(repl), path); if ((p = has_packed_and_bad(r, repl->hash)) != NULL) @@ -1664,7 +1672,9 @@ oid_to_hex(repl), p->pack_name); obj_read_unlock(); - return NULL; + errno = 0; + error("error ignored"); + return strdup(""); } void *read_object_with_reference(struct repository *r, @@ -2473,10 +2483,12 @@ } git_inflate_end(stream); + /* if (status != Z_STREAM_END) { error(_("corrupt loose object '%s'"), oid_to_hex(expected_oid)); return -1; - } + }*/ + if (stream->avail_in) { error(_("garbage at end of loose object '%s'"), oid_to_hex(expected_oid)); 

A quick way if you have a change in your current project and don't want to lose it, move your current project somewhere, clone the project from GitHub to this folder and make some change and try to commit again.

Or just delete the repository and clone it again. It worked for me.

I wanted to add this as a comment under Zoey Hewil's awesome answer above, but I don't currently have enough rep to do so, so I have to add it here and give credit for her work :P

If you're using Poshgit and are feeling exceptionally lazy, you can use the following to automatically extract your URL from your Git configuration and make an easy job even easier. Standard caveats apply about testing this on a copy/backing up your local repository first in case it blows up in your face.

$config = get-content .git\config $url = $config -match " url = (?<content>.*)" $url = $url.trim().Substring(6) $url move-item -v .git .git_old; git init; git remote add origin "$url"; git fetch; git reset origin/master --mixed 

What method of repair is best depends on the kind of damage that was done. I accidentally had a sed search and replace recurse into the .git directory, which corrupted the object files.

If all data is still intact on the remote, then fixing this is surprisingly easy:

rm -rf .git/objects/?? .git/objects/pack/* git fetch 

This basically removes all local objects and git fetch will rebuild them.

For my part it was a problem of case sensitive (I work with a GitLab on Linux and Visual Studio on Windows). I had two identical files in GitLab (path + filename) but in two differents paths because of the difference in lowercase/uppercase ".../path1/file 1" and ".../PATH1/file1". But Windows isn't case sensitive so it's two files become one ! For me the solution was to delete the duplicate directory/file on origin then (re)clone the project.