Re: Recover broken git repository?

[Alex Riesen <raa.lkml@gmail.com>]

On Tue, Jul 14, 2009 at 15:20, Florian Breitwieser<florian.bw@gmail.com> wrote:
> I have problems with my git repository, attached below are the steps I tried
> to resolve it. But now I am stuck. Is there any good way to recover?

There are recovery instructions all over the web, and on this mailing list.
Try googling for "git repository corruption recovery".
There is even one in Git's repository:

  Documentation/howto/recover-corrupted-blob-object.txt

> $ git commit -m "Some message"
> error: invalid object 1086b1c606a04bcb78b92d1d411a299d20d18034

Looks like you have hit a genuine repository corruption.

You can try to look for the object in all copies of the project (or just in any
projects you possibly have laying around) and copy it into you repo.
To test if the object is present in a repo:

  git cat-file -t 1086b1c606a04bcb78b92d1d411a299d20d18034

You can just copy (or reference in .git/objects/info/alternates) the whole
repo containing the object in the broken repo. You can cleanup unused
objects afterwards.

> fatal: Error building trees

You can try "git log --pretty=raw --raw --no-abbrev HEAD | less" and
look for the first commit which introduced the invalid object. The history
up to this commit must be intact, BTW. Try to find out what object it was.
If it was a file, than maybe you have the original source somewhere,
or the latest version is present and good enough. Then you can checkout
the good commit, introduce the file from the source, commit, and cherry-pick
all the newer commits on top of it.
If it was a tree, you can try to guess what files did it contain in the
commit which references it and try to rebuild it by using git add and
git write-tree (the latter prints the SHA1 of the generated tree on
stdout, so you can retry indefinitely).
If it happens to be a commit (you'll find the SHA1 in parents of
the good commits, but it does not look like it is the case), you can
try git fsck --lost-found to find all the commits which are not
referenced, try connecting them (by using grafts, for example.
Or checkout and cherry-pick described above).

> $ git-fsck --full
> dangling tree c2549a3cdd83098a523cb707f217f4656cde7eb5
>
> $ git prune

Now that was dangerous. When something was unreferenced
(but useful) now it is lost.