Как восстановить объекты Git, поврежденные в результате сбоя жесткого диска? - PullRequest
91 голосов
/ 29 апреля 2009

У меня был сбой жесткого диска, из-за которого некоторые файлы хранилища Git были повреждены. При запуске git fsck --full я получаю следующий вывод:

error: .git/objects/pack/pack-6863e0a0e4b4ded6090fac5d12eba6ca7346b19c.pack SHA1 checksum mismatch
error: index CRC mismatch for object 6c8cae4994b5ec7891ccb1527d30634997a978ee from .git/objects/pack/pack-6863e0a0e4b4ded6090fac5d12eba6ca7346b19c.pack at offset 97824129
error: inflate: data stream error (invalid code lengths set)
error: cannot unpack 6c8cae4994b5ec7891ccb1527d30634997a978ee from .git/objects/pack/pack-6863e0a0e4b4ded6090fac5d12eba6ca7346b19c.pack at offset 97824129
error: inflate: data stream error (invalid stored block lengths)
error: failed to read object 0dcf6723cc69cc7f91d4a7432d0f1a1f05e77eaa at offset 276988017 from .git/objects/pack/pack-6863e0a0e4b4ded6090fac5d12eba6ca7346b19c.pack
fatal: object 0dcf6723cc69cc7f91d4a7432d0f1a1f05e77eaa is corrupted

У меня есть резервные копии репозитория, но единственная резервная копия, содержащая файл пакета, уже повреждена. Поэтому я думаю, что мне нужно найти способ извлечь отдельные объекты из разных резервных копий и как-то проинструктировать Git создать новый пакет только с правильными объектами.

Не могли бы вы дать мне подсказки, как исправить мой репозиторий?

Ответы [ 7 ]

81 голосов
/ 29 апреля 2009

В некоторых предыдущих резервных копиях ваши плохие объекты могли быть упакованы в разные файлы или еще могут быть незакрепленными объектами. Таким образом, ваши объекты могут быть восстановлены.

Кажется, в вашей базе данных есть несколько плохих объектов. Так что вы можете сделать это вручную.

Из-за git hash-object, git mktree и git commit-tree не пишите объекты, потому что они найдены в пакете, затем начните делать это:

mv .git/objects/pack/* <somewhere>
for i in <somewhere>/*.pack; do
  git unpack-objects -r < $i
done
rm <somewhere>/*

(Ваши пакеты извлекаются из хранилища и снова распаковываются в нем; в базе данных теперь только хорошие объекты)

Вы можете сделать:

git cat-file -t 6c8cae4994b5ec7891ccb1527d30634997a978ee

и проверьте тип объекта.

Если используется тип blob: получить содержимое файла из предыдущих резервных копий (с помощью git show или git cat-file или git unpack-file; тогда вы можете git hash-object -w переписать объект в вашем текущем хранилище.

Если тип дерева: вы можете использовать git ls-tree для восстановления дерева из предыдущих резервных копий; затем git mktree, чтобы снова записать его в ваш текущий репозиторий.

Если типом является коммит: то же самое с git show, git cat-file и git commit-tree.

Конечно, я бы сделал резервную копию вашей оригинальной рабочей копии перед началом этого процесса.

Также взгляните на Как восстановить поврежденный объект BLOB-объекта .

38 голосов
/ 04 мая 2009

Banengusk выводил меня на правильный путь. Для дальнейшего ознакомления я хочу опубликовать шаги, которые я предпринял, чтобы исправить повреждение хранилища. Мне посчастливилось найти все необходимые объекты либо в старых пакетах, либо в резервных копиях репозитория.

# Unpack last non-corrupted pack
$ mv .git/objects/pack .git/objects/pack.old
$ git unpack-objects -r < .git/objects/pack.old/pack-012066c998b2d171913aeb5bf0719fd4655fa7d0.pack
$ git log
fatal: bad object HEAD

$ cat .git/HEAD 
ref: refs/heads/master

$ ls .git/refs/heads/

$ cat .git/packed-refs 
# pack-refs with: peeled 
aa268a069add6d71e162c4e2455c1b690079c8c1 refs/heads/master

$ git fsck --full 
error: HEAD: invalid sha1 pointer aa268a069add6d71e162c4e2455c1b690079c8c1
error: refs/heads/master does not point to a valid object!
missing blob 75405ef0e6f66e48c1ff836786ff110efa33a919
missing blob 27c4611ffbc3c32712a395910a96052a3de67c9b
dangling tree 30473f109d87f4bcde612a2b9a204c3e322cb0dc

# Copy HEAD object from backup of repository
$ cp repobackup/.git/objects/aa/268a069add6d71e162c4e2455c1b690079c8c1 .git/objects/aa
# Now copy all missing objects from backup of repository and run "git fsck --full" afterwards
# Repeat until git fsck --full only reports dangling objects

# Now garbage collect repo
$ git gc
warning: reflog of 'HEAD' references pruned commits
warning: reflog of 'refs/heads/master' references pruned commits
Counting objects: 3992, done.
Delta compression using 2 threads.
fatal: object bf1c4953c0ea4a045bf0975a916b53d247e7ca94 inconsistent object length (6093 vs 415232)
error: failed to run repack

# Check reflogs...
$ git reflog

# ...then clean
$ git reflog expire --expire=0 --all

# Now garbage collect again
$ git gc       
Counting objects: 3992, done.
Delta compression using 2 threads.
Compressing objects: 100% (3970/3970), done.
Writing objects: 100% (3992/3992), done.
Total 3992 (delta 2060), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
# Done!
15 голосов
/ 27 марта 2014

Сначала попробуйте выполнить следующие команды (при необходимости повторите снова):

$ git fsck --full
$ git gc
$ git gc --prune=today
$ git fetch --all
$ git pull --rebase

И тогда у вас все еще есть проблемы, попробовать можете:

  • удалить все поврежденные объекты, например

    fatal: loose object 91c5...51e5 (stored in .git/objects/06/91c5...51e5) is corrupt
    $ rm -v .git/objects/06/91c5...51e5
    
  • удалить все пустые объекты, например

    error: object file .git/objects/06/91c5...51e5 is empty
    $ find .git/objects/ -size 0 -exec rm -vf "{}" \;
    
  • проверить сообщение "битая ссылка" по:

    git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
    

    Это скажет вам, из какого файла пришел поврежденный BLOB-объект!

  • для восстановления файла вам может повезти, и это может быть версия, которую вы уже проверили в своем рабочем дереве:

    git hash-object -w my-magic-file
    

    еще раз, и если он выдаст недостающий SHA1 (4b945 ..), то теперь все готово!

  • Если предположить, что это была старая версия, которая была сломана, самый простой способ сделать это:

    git log --raw --all --full-history -- subdirectory/my-magic-file
    

    и это покажет вам весь журнал для этого файла (обратите внимание, что дерево, которое у вас было, может не быть деревом верхнего уровня, поэтому вам нужно выяснить, в каком подкаталоге оно было самостоятельно), тогда вы можете Теперь снова создайте отсутствующий объект с помощью hash-object.

  • , чтобы получить список всех ссылок с отсутствующими коммитами, деревьями или каплями:

    $ git for-each-ref --format='%(refname)' | while read ref; do git rev-list --objects $ref >/dev/null || echo "in $ref"; done
    

    Может быть невозможно удалить некоторые из этих ссылок с помощью обычных команд branch -d или tag -d, так как они умрут, если git заметит повреждение. Так что используйте вместо этого сантехническую команду git update-ref -d $ ref. Обратите внимание, что в случае локальных ветвей эта команда может оставить устаревшую конфигурацию веток в .git / config. Его можно удалить вручную (см. Раздел [branch "$ ref"]).

  • После того, как все ссылки очищены, в журнале все еще могут быть нарушенные коммиты. Вы можете очистить все reflogs, используя git reflog expire --expire = now --all. Если вы не хотите потерять все свои reflogs, вы можете найти отдельные refs для сломанных reflogs:

    $ (echo HEAD; git for-each-ref --format='%(refname)') | while read ref; do git rev-list -g --objects $ref >/dev/null || echo "in $ref"; done
    

    (Обратите внимание на добавленную опцию -g для git rev-list.) Затем используйте git reflog expire --expire = now $ ref для каждого из них. Когда все испорченные ссылки и повторные журналы исчезнут, запустите git fsck --full, чтобы убедиться, что хранилище чистое. Висячие объекты в порядке.


Ниже вы можете найти подробное использование команд, которые потенциально могут привести к потере ваших данных в вашем git-хранилище, если их не использовать разумно, поэтому сделайте резервную копию, прежде чем случайно нанести дальнейший ущерб вашему git. Попробуйте на свой страх и риск, если знаете, что делаете.


Чтобы вытащить текущую ветвь поверх восходящей ветки после выборки:

$ git pull --rebase

Вы также можете попробовать оформить новую ветку и удалить старую:

$ git checkout -b new_master origin/master

Чтобы найти поврежденный объект в git для удаления, попробуйте следующую команду:

while [ true ]; do f=`git fsck --full 2>&1|awk '{print $3}'|sed -r 's/(^..)(.*)/objects\/\1\/\2/'`; if [ ! -f "$f" ]; then break; fi; echo delete $f; rm -f "$f"; done

Для OSX используйте sed -E вместо sed -r.


Другая идея состоит в том, чтобы распаковать все объекты из файлов пакета, чтобы восстановить все объекты внутри .git / objects, поэтому попробуйте выполнить следующие команды в своем хранилище:

$ cp -fr .git/objects/pack .git/objects/pack.bak
$ for i in .git/objects/pack.bak/*.pack; do git unpack-objects -r < $i; done
$ rm -frv .git/objects/pack.bak

Если приведенное выше не помогает, вы можете попробовать выполнить rsync или скопировать объекты git из другого репозитория, например,

$ rsync -varu git_server:/path/to/git/.git local_git_repo/
$ rsync -varu /local/path/to/other-working/git/.git local_git_repo/
$ cp -frv ../other_repo/.git/objects .git/objects

Исправить сломанную ветку при попытке оформить заказ следующим образом:

$ git checkout -f master
fatal: unable to read tree 5ace24d474a9535ddd5e6a6c6a1ef480aecf2625

Попытайтесь удалить его и снова оформить заказ:

$ git branch -D master
$ git checkout -b master github/master

В случае, если git переведет вас в отдельное состояние, извлеките master и объедините в нем отдельную ветвь.


Другая идея - рекурсивно перебазировать существующий мастер:

$ git reset HEAD --hard
$ git rebase -s recursive -X theirs origin/master

Смотри также:

2 голосов
/ 30 октября 2015

Вот шаги, которые я выполнил для восстановления поврежденного объекта BLOB-объекта.

1) Определить поврежденный блоб

git fsck --full
  error: inflate: data stream error (incorrect data check)
  error: sha1 mismatch 241091723c324aed77b2d35f97a05e856b319efd
  error: 241091723c324aed77b2d35f97a05e856b319efd: object corrupt or missing
  ...

Поврежденный BLOB-объект 241091723c324aed77b2d35f97a05e856b319efd

2) Переместить поврежденный блоб в безопасное место (на всякий случай)

mv .git/objects/24/1091723c324aed77b2d35f97a05e856b319efd ../24/

3) Получить родителя испорченного блоба

git fsck --full
  Checking object directories: 100% (256/256), done.
  Checking objects: 100% (70321/70321), done.
  broken link from    tree 0716831e1a6c8d3e6b2b541d21c4748cc0ce7180
              to    blob 241091723c324aed77b2d35f97a05e856b319efd

Родительский хэш 0716831e1a6c8d3e6b2b541d21c4748cc0ce7180 .

4) Получить имя файла, соответствующее поврежденному BLOB-объекту

git ls-tree 0716831e1a6c8d3e6b2b541d21c4748cc0ce7180
  ...
  100644 blob 241091723c324aed77b2d35f97a05e856b319efd    dump.tar.gz
  ...

Найдите этот конкретный файл в резервной копии или в исходном репозитории git (в моем случае это dump.tar.gz ). Затем скопируйте его где-нибудь в вашем локальном хранилище.

5) Добавить ранее поврежденный файл в базу данных объектов git

git hash-object -w dump.tar.gz

6) Празднуйте!

git gc
  Counting objects: 75197, done.
  Compressing objects: 100% (21805/21805), done.
  Writing objects: 100% (75197/75197), done.
  Total 75197 (delta 52999), reused 69857 (delta 49296)
1 голос
/ 08 ноября 2015

Вот две функции, которые могут помочь, если ваша резервная копия повреждена, или у вас также есть несколько частично поврежденных резервных копий (это может произойти, если вы делаете резервную копию поврежденных объектов).

Запустите оба репозитория, который вы пытаетесь восстановить.

Стандартное предупреждение: используйте, только если вы действительно в отчаянии и сделали резервную копию своего (поврежденного) репо. Это может ничего не решить, но, по крайней мере, должно подчеркнуть уровень коррупции.

fsck_rm_corrupted() {
    corrupted='a'
    while [ "$corrupted" ]; do
        corrupted=$(                                  \
        git fsck --full --no-dangling 2>&1 >/dev/null \
            | grep 'stored in'                          \
            | sed -r 's:.*(\.git/.*)\).*:\1:'           \
        )
        echo "$corrupted"
        rm -f "$corrupted"
    done
}

if [ -z "$1" ]  || [ ! -d "$1" ]; then
    echo "'$1' is not a directory. Please provide the directory of the git repo"
    exit 1
fi

pushd "$1" >/dev/null
fsck_rm_corrupted
popd >/dev/null

и

unpack_rm_corrupted() {
    corrupted='a'
    while [ "$corrupted" ]; do
        corrupted=$(                                  \
        git unpack-objects -r < "$1" 2>&1 >/dev/null \
            | grep 'stored in'                          \
            | sed -r 's:.*(\.git/.*)\).*:\1:'           \
        )
        echo "$corrupted"
        rm -f "$corrupted"
    done
}

if [ -z "$1" ]  || [ ! -d "$1" ]; then
    echo "'$1' is not a directory. Please provide the directory of the git repo"
    exit 1
fi

for p in $1/objects/pack/pack-*.pack; do
    echo "$p"
    unpack_rm_corrupted "$p"
done
1 голос
/ 29 апреля 2009

Git Checkout может фактически выбирать отдельные файлы из ревизии. Просто дайте ему хеш коммита и имя файла. Более подробная информация здесь.

Я полагаю, что самый простой способ исправить это безопасно - вернуться к самой последней незафиксированной резервной копии, а затем выборочно выбрать неиспорченные файлы из новых коммитов. Удачи!

0 голосов
/ 27 марта 2017

Я решил эту проблему, добавив некоторые изменения, такие как git add -A и git commit.

...