| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
Some corrupt objects can cause it to say the object is several TB, which
led to OOM.
Added some fork overhead, but it shouldn't be too bad; this is only run
against objects fsck outputs, and most of the time that is only corrupt
objects, and objects that refer to them.
|
|
|
|
|
|
|
| |
Apparently some corruption to an object can cause cat-file to say it's N
bytes long, but only output N-M bytes of data. This causes Git.CatFile
to stall waiting for the rest. To fix, add a 1 minute timeout to the
cat-file, which should be enough time to read any reasonable object.
|
|
|
|
| |
This code needs to be refactored..
|
|
|
|
|
|
|
|
| |
In this case, fsck failed once for some reason that was corrected by
fetching.
But then it failed again due to an object with a bad type, which remained
in tree after fetching from origin. So, let cleanCorruptObjects run again
after fetching.
|
|
|
|
|
| |
Aguably, I should make cat-file only throw IO exceptions, but currently it
throws some errors too.
|
| |
|
|
|
|
|
|
|
| |
unpack-objects does nothing unless the pack is moved out of the packs
directory.
Also, unpack any packs recevied when fetching.
|
| |
|
|
|
|
|
|
| |
It turned out to be broken, and led to failures.
6d67245728bbbc07ad1eeaf5b3c49f64c6bbcd11 was a better fix for the problem
that code tried to fix.
|
|
|
|
| |
Must contains "ref: refs/" or git rejects it
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Sometimes git fsck outputs no shas even with --verbose, but fails, due to
badly corrupt objects. The best thing to do in this situation is to try to
pull and rsync from remotes, hoping that the bad objects will be
overwritten.
|
| |
|
|
|
|
| |
treat the repository as a git repo.
|
| |
|
|
|
|
|
| |
In this case, the index problem prevented fsck from finding the other
problems.
|
| |
|
| |
|
|
|
|
|
| |
I suspect this might sometimes corrupt the **source** repo, so use with
caution!
|
| |
|
|
|