How can I fix a corrupted Git repository?

Question

I tried cloning my repository which I keep in my Ubuntu One folder to a new machine, and I got this:

cd ~/source/personal
git clone ~/Ubuntu\ One\ Side\ Work/projects.git/

Cloning into 'projects'...
done.
fatal: unable to read tree 29a422c19251aeaeb907175e9b3219a9bed6c616

So I tried looking at the many other questions like this that have been asked here and most of them say to run git fsck --full and then I get this when I try that.

cd ~/Ubuntu\ One\ Side\ Work/projects.git
git fsck --full

Checking object directories: 100% (256/256), done.
Checking objects: 100% (447/447), done.
broken link from  commit 235ae1f48701d577d71ebd430344a159e5ba4881
              to  commit 984c11abfc9c2839b386f29c574d9e03383fa589
broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b
              to    blob 25a742dff0a403b2b3884f2ffddf63eb45721fac
broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b
              to    blob dd4e97e22e159a585b20e21028f964827d5afa4e
broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b
              to    tree 29a422c19251aeaeb907175e9b3219a9bed6c616
broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b
              to    tree 8084e8e04d510cc28321f30a9646477cc50c235c
broken link from    tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628
              to    blob a0daa0c1567b55d8de2b4d7a3bc010f58c047eab
broken link from    tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628
              to    blob e9052d35bfb6d30065b206fc43f4200a04d5281b
broken link from    tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628
              to    blob 1a3a5e4dd2502ac121c22f743c4250e254a94eeb
broken link from    tree 4aa336dc1a5838e8918e03b85580069d83f4ad09
              to    tree 8cc55ec952dc192a233e062201d1e7e873ac3db0
broken link from    tree e5674a91a53e15575a1f3bf5786bc5cc719fb483
              to    blob 4a994e1e7bb7ce28dcec98bad48b9a891d7dec51
broken link from    tree e5674a91a53e15575a1f3bf5786bc5cc719fb483
              to    blob ac033bf9dc846101320c96a5ce8aceb8c96ec098
broken link from    tree 252ab84542264e1589576b6ee51e7a31e580a0e2
              to    tree 2069041cd5950e529e2991d37b7290ec021d90d4
broken link from    tree 2d4964aa4d4f5d8c7228518ce72ef6a63f820c6d
              to    blob d83690e1b9a6bdd8a08754b38231799acefcb2ab
broken link from    tree c7192e82fc581bd6448bda1a25e8729bdac5f4ff
              to    blob 30d54d47ae82add1917ca173d42e58b396df580b
broken link from    tree 7c66306901fc71389623286936cef172d4ffe408
              to    blob bc7e05d705401273b1df4e939de0f540597c0931
broken link from    tree 0940f5fd227d4c84d6e6749d872db50a4522ae3a
              to    tree 923767594ac22023e824948d65622fe5b407d1a1
broken link from    tree 8eadcd2a971e8357d24f0d80f993d2963452209f
              to    blob 2598bde3dc8cb80ee49510b8159344004b88645f
broken link from    tree ffa302dd0d969172ef23caeefe856ab2f57a4e4d
              to    blob d6925fa431be1ac585bf9a481e98f75107a6e6fb
broken link from    tree 7045b8870a49ce30a2027537a96d73d162bda773
              to    blob 25688652dea26f61f576ca1b52b9d1a18fbfd01d
broken link from    tree 37e4705d34bd440ce681ae32ae9a180a13256d72
              to    tree 246f564d4cee53339b8a4244f3173b61caa518eb
missing blob d6925fa431be1ac585bf9a481e98f75107a6e6fb
missing blob ac033bf9dc846101320c96a5ce8aceb8c96ec098
missing tree 29a422c19251aeaeb907175e9b3219a9bed6c616
missing tree 8084e8e04d510cc28321f30a9646477cc50c235c
missing blob 30d54d47ae82add1917ca173d42e58b396df580b
missing tree 8cc55ec952dc192a233e062201d1e7e873ac3db0
missing blob e9052d35bfb6d30065b206fc43f4200a04d5281b
dangling tree 4b26e95db542c72ac4a22ec25abe38fb2de79752
missing blob d83690e1b9a6bdd8a08754b38231799acefcb2ab
missing blob 25a742dff0a403b2b3884f2ffddf63eb45721fac
missing tree 923767594ac22023e824948d65622fe5b407d1a1
missing blob 25688652dea26f61f576ca1b52b9d1a18fbfd01d
missing blob 2598bde3dc8cb80ee49510b8159344004b88645f
dangling tree 3a683869f1bb0c1634de75700c316b3b36570dbd
dangling blob 4098d30843380d798a811f1aa9a02994f0dbbb27
missing tree 2069041cd5950e529e2991d37b7290ec021d90d4
missing blob 4a994e1e7bb7ce28dcec98bad48b9a891d7dec51
missing blob 1a3a5e4dd2502ac121c22f743c4250e254a94eeb
missing blob a0daa0c1567b55d8de2b4d7a3bc010f58c047eab
dangling tree 6c7b5162aa7a303fa3fe8dc393c5da564e309521
missing commit 984c11abfc9c2839b386f29c574d9e03383fa589
missing blob bc7e05d705401273b1df4e939de0f540597c0931
missing blob dd4e97e22e159a585b20e21028f964827d5afa4e
missing tree 246f564d4cee53339b8a4244f3173b61caa518eb
dangling commit a01f5c1e5315dc837203d6dee00d3493be9c5db9

That looks really bad. When I do a git log | head I get this

git log | head

error: Could not read 984c11abfc9c2839b386f29c574d9e03383fa589
fatal: Failed to traverse parents of commit 235ae1f48701d577d71ebd430344a159e5ba4881
commit 2fb0d2d0643b445440f01b164f11ee9ee71fca48
Author: christopher <[email protected]>
Date:   Wed Aug 7 15:51:42 2013 -0400

    finishing chapter 7

Other questions here have said to look at ./git/refs/heads/master. It's a bare repo and refs/heads/ exists but refs/heads/master does not. HEAD in the bare repository says ref: refs/heads/master though.

packed-refs does say this though

# pack-refs with: peeled
2fb0d2d0643b445440f01b164f11ee9ee71fca48 refs/heads/master

Still other questions have suggested running git reflog and no output shows up when I run that.

So I really have no idea what to do here. What strategy should be taken? Is it possible to reset head to this last commit on Aug 7?

Doing a git log and going to the bottom of the screen output shows this:

commit 996e03b949aea176238e3c7a8452700bbb987ac9
Author: christopher <christopher@christopher>
Date:   Wed Jul 3 23:00:44 2013 -0400

    many many changes
error: Could not read 984c11abfc9c2839b386f29c574d9e03383fa589
fatal: Failed to traverse parents of commit 235ae1f48701d577d71ebd430344a159e5ba4881

That seems to be preventing the Git prune from working.

Toneme

This isn't much help but: do not store Git repos in Dropbox or any other sync services. Git isn't built to handle another program randomly locking and rewriting files while it's doing something else. – Acred

Related: https://mcmap.net/q/22349/-using-dropbox-as-git-working-directory-across-multiple-machines-commits-don-39-t-sync-perfectly/1301972 – Medicine

Nearly all answers assume one can simply re-clone from some uncorruptible remote origin. Here's the problem... What if you are the origin, and you're corrupted? Right. So, here: git-repair is a program that will run git fsck and try pretty hard to fix any problems it encounters. git-repair.branchable.com It seems quite capable, and though you might end up having to copy (if you can!) objects from a backup (you have a backup, right?), it should save you a lot of time by salvaging whatever it can and leaving you the real work, not lots of automatable tasks. No affiliation, etc. – Genny

Answer 1

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

Backsaw

Spectacular, I made a backup of my project and tried your solution. Git was corrupted fairly badly somehow. I tried your solution and it worked perfectly thank you so much. – Hamlen

didn't use the script as I'm on Windows, but those commands just saved my .git folder that was showing new repo for every save made on any tracked file (so I ended up with like 50 master repositories before I tried this fix) – Aperient

I didn't use the script, but commands ave been very useful. I'd try to make them more general purpose, to improve your answer. Thanks a lot, btw. – Amenra

If you have an improvement to make, make an edit. This was as general as I could make it with my level of knowledge. – Backsaw

I was able to restore my .git folder after doing this. I found git reset origin/master --hard was more useful than --mixed. – Reception

The intent of using --mixed was that any changes to the working tree wouldn't be lost, eg if you noticed the repo was broken only after trying to make a commit. – Backsaw

Great. In case there are submudules which don't contain changes, remove them first and then do submodule init to get them again. – Candlefish

If i have no access to the remote repo what i can do ? – Adna

@Adna Unfortunately, this solution is only applicable for the case where you have a valid and accessible remote repository. Some of the other answers address the case of an inaccessible or corrupt remote. – Backsaw

Seems that the script is not working if the repository is accessed with ssh... it is trying to wget something like [email protected]:username – Kenny

It's been a while since I wrote this, it looks like the wget is just to test that the repo is reachable, but that may not be necessary. – Backsaw

Since I visit this page so often, let me add those quite reminders that are so helpful: git branch -m temp_delete, then somehow switch branch to origin/master, then git branch -d temp_delete, for a clean checkout. – Increscent

If you want keep your old stash, copy these files from .git-old: - .git-old/objects - .git-old/refs/stash - .git-old/logs/refs/stash – Batruk

And after running the script you'll have set your upstream again: git branch -u origin/master master – Batruk

If the local branch is not master, you need execute git init -b <local-branch-name> instead of git init, and replace master with <local-branch-name> in git reset origin/master --mixed. – Illegible

More likely to be main than master now because of a change in GitHub conventions. code git reset origin/main --mixed # Force update to old history – Busybody

Regarding the submodules, cp -r .git_old/modules .git/modules worked for me in saving the submodules I had on disk. – Albaugh

Answer 2

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.

Medicine

I just ran into this issue and wanted to point this out since it's not in your answer, but my problem was just a simple permissions issue. error: Could not read abcde My repo is managed by GitLab and it was creating files that my user couldn't read. A sudo chown later and I was good to go. – Mabuse

Full Restores and Re-Initialization saved my life :) I've also run a git pull origin master --allow-unrelated-histories in order to pull last version of my code from remote repo – Sovran

and after a re-initialisation would you then need to do a force push of the master/main branch up to the same remote to completely reset the remote version as well? – Trollop

Answer 3

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.

Arriviste

git-repair is indeed a very useful tool. It helped me to recover a repository. The problem with most other methods is that you lose your stashes, which was not an option for me. – Pantie

Answer 4

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++).

Sympathy

You can clone from a git bundle file but as of 2.37 you can't push new refs into one. So a bundle file can be an effective backup of the repo but it can't be used as a two-way remote. – Tourmaline

Answer 5

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

Smug

In some cases, git won't let you fetch if certain objects are corrupted, so you need to re-initialise your repo first. – Backsaw

This didn't work for me when I had fatal: pack has 13 unresolved deltas. – Rodd

Assumes a work tree when the question was about a repo. – Posen

Answer 6

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.

Crossway

Answer 7

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

Percentage

Answer 8

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

Cassycast

Answer 9

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.

Feminism

Answer 10

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 :)

Limn

This 'unpack-objects' trick worked for me! I also had a tag that was somehow bad and pointing to that object. git gc --prune=now followed by git fetch got it back. – Clothbound

Answer 11

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.

Eisen

Answer 12

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 :)

Bristol

Answer 13

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.

Sunbathe

Answer 14

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

Jagannath

Answer 15

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));

Extravaganza

While I very like git, but... I simply can not understand, why it was not implemented in an sqlite backend. Then it could be fixed with any sqlite recovery tool. – Extravaganza

Answer 16

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

Limn

Answer 17

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.

Erde

Answer 18

This command worked for me:

git reset --mixed

Gnosis