web-dev-qa-db-ja.com

Gitの破損したファイル

最近、次のコマンドを使用してgitリポジトリ履歴からいくつかのフォルダーを削除しました。

git filter-branch --index-filter 'git rm -r --cached var' -- --all

残念ながら、このリポジトリからプルすることはできません。これは、取得したエラーセットです。

git pull
remote: Counting objects: 3953, done.
remote: Compressing objects: 100% (2810/2810), done.
error: garbage at end of loose object '4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0'
fatal: object 4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 is corrupted
fatal: index-pack failed
gitrepositoryfile-corruption
8
mnml

ある種の魂 スクリプトを書いた これを自動的に（そしてより徹底的に）行うために、しかし回復へのプロセスは基本的にこれです：

  1. Hexdumpを使用して、ガベージを報告するファイルを調べます。

    $ hexdump .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0

    ゼロのスパンが非常に大きいファイルの一部を探しています。そのようなスパンが複数ある場合は、ゼロ以外のデータの小さな実行が含まれている場合でも、最初の巨大なゼロのセットだけを検討するときに幸運がありました（N = 2）。これは、gitが不満を言っている「ゴミ」です。

    ...
0000500 0532 0302 0000 0000 0000 0000 0000 0000    # <-- Beginning here...
0000510 0000 0000 0000 0000 0000 0000 0000 0000
*
0001000             # ... almost 3kb of zeros.

    これから、オブジェクトの実際のサイズを判別できます。ここでは、0x504または1,284バイトになります。

  2. オブジェクトのバックアップコピーを作成します。間違ったゼロのセットを選択した場合は、別のセットで再試行できます。

    $ cp .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0 ~/old_4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0

  3. ファイルを適切な長さに切り捨てます。

    $ truncate -s 1284 .git/objects/4b391c2cc93ccc8d2f7262335629a7f81d6bcbe0

破損したオブジェクトは修正されます。それが唯一のものであると仮定すると、リポジトリのクローン作成/プッシュ/プルは期待どおりに機能するはずです。

私の情報源を引用すると、私は同じ問題を経験したと思いますが、私の場合はUbuntu 10.4（カーネル2.6.32-23-generic）を使用しています。この場合、それはまだ追跡されていないファイルシステムのバグです。この件に関しては ecryptfs に未解決の問題があり、 関連するusenetスレッド にも問題があります。解決策への道のりで、StackOverflowで 便利な回答と要約 を見つけました。 リンクされた記事 は非常に興味深いものでしたが、最終的には別の方法で進みました。

7
Andres Jaan Tack