gitツリーに重複したファイルのエントリが含まれています

Question

約20件のコミットが戻ってしまい、いくつかの奇妙なことが起こりました。今のgit fsckのショー：

Checking object directories 100% (256/256), done. 
error in tree ee2060e71cb36d33be5ddc1fe9ca8d7dd0ab35cd: contains duplicate file entries 
Checking objects: 100% (8633/8633), done. 

とGitのショーee2060は示しています

File1.cs 
File2.cs 
File2.cs 
File2.cs 
File3.cs 

これは私のリモートにプッシュするから私を妨げています。 git pushは次のように表示します：

error: unpack failed: index-pack abnormal exit 
To https://github.com/username/Project.git 
! [remote rejected] master -> master (n/a (unpacker error)) 
error: failed to push some refs to 'https://github.com/username/Project.git' 

私は再パックとガベージコレクションを試みました。どうすればこの問題を解決できますか？

Answer 1

私は最終的に問題が

が上のリモートとしてファイルシステムからの私の台無しにレポを追加発生する前にのみコミットを含まgithubの、より新鮮なクローンを行うには、次

1. を行うことによって、レポを固定新しいクローン

2. は苦労して新しいクローン

   git checkout fe3254FIRSTCOMMITAFTERORIGIN/MASTER/HEAD . // note the dot at the end 
   // without the dot, you move your head to the commit instead of the commit 
   // to the working copy, and seems to bring the corrupt object into your good clone 
   

3. commiの作業コピーに悪いレポからコミットチェックアウトtはそれぞれ順番に、手動で他のレポ
4. からコミットメッセージをコピーするリモート

5. ごみから破損レポを削除Gitのfsckは重複ファイルエントリ

を示さないように喜ん

git gc --aggressive --prune=now 

6. ウィープを剪定+集めます

Answer 2

コミットを再度ベースに再設定すると修正される可能性があります。それが助けにならない場合は、gitの低レベルコマンド（git-cat-file）を使って、この奇妙なツリーオブジェクトがどのコミットに含まれているかを確認し、複製することなくツリーの正しいバージョンを再構築することができます。しかし、これを修正できる自動ツールはわかりません。おそらく、奇妙なものに既にリンクしているすべてのツリーとコミットオブジェクトを変更する必要があります。

ちなみに、git ls-tree ee2060は、そこに参照されているファイルのように、破損したツリーにあるデータの詳細を表示する必要があります。

Answer 3

checkout問題のあるコミットの直前に新しいブランチを作成します。今問題のあるコミットからファイルをチェックアウトします。今度は、同じメッセージを使用して追加してコミットします（-Cオプションを使用してください）。コミットの残りの部分を繰り返します。完了したら、もう一方のブランチをこの正しいブランチにポイントするようにリセットします。あなたはそれを押すことができます。

Answer 4

git-replaceとgit-mktreeを使ってこれを修正しました。基本的には、壊れたツリーオブジェクトを保持しますが、すべてのリンクをオーバーライドして新しいオブジェクトをポイントさせます。

1. まず私たちは、悪い木をつかむ：git ls-tree bad_tree_hash > tmpfile.txt これはあなたの悪い木を書き出します。たとえば、次のように

   040000·tree·3cdcc756ee0ed636c44828927126911d0ab28a18 → xNotAlphabetic 
   040000·tree·4ad0d8ef014b8cc09c95694399254eff43217bfb → EXT 
   040000·tree·d65085e4a05ea9ac8b79e37b87202dd64d402c2e → duplicateFolder 
   040000·tree·d65085e4a05ea9ac8b79e37b87202dd64d402c2e → duplicateFolder 
   040000·tree·fd0661d698ace91135a8473b26707892b7c89c32 → ToolTester 
   040000·tree·d65085e4a05ea9ac8b79e37b87202dd64d402c2e → duplicateFolder 
   

   NB、・&→は空白[スペース]で、[タブ]

2. 次に、（問題のある行を削除、テキストを編集し、Unixスタイルの語尾に保存すなわち、CRLFではなくLFのみ）。 デモの目的のために別名a55115e4a05ea9ac8b79e37b872024d64d4r2c2enew_tree_hash

3. 次へ：新しい、固定のツリーオブジェクトを作成し、それを保存し、新しいハッシュを返します

   040000·tree·4ad0d8ef014b8cc09c95694399254eff43217bfb → EXT 
   040000·tree·d65085e4a05ea9ac8b79e37b87202dd64d402c2e → duplicateFolder 
   040000·tree·fd0661d698ace91135a8473b26707892b7c89c32 → ToolTester 
   040000·tree·3cdcc756ee0ed636c44828927126911d0ab28a18 → xNotAlphabetic 
   

4. タイプcat tmpfile.txt | git mktree：この例では、我々はこれを作りますgit replaceは新しい参照を作成し、これまでのすべてのインシデントリンクに新しい固定オブジェクトを代わりに使用させます。 git replace bad_tree_hash new_tree_hash

これはあなたの当面の問題を解決します。興味がある場合は、.git/refs/replaceフォルダの上書きリンクをご覧ください。

---

悪いツリーオブジェクトを使用すると、git fsckでリポジトリのチェックを行うたび警告を生成していきますが、それは無視することができ、かつ、すべてのコミットと他のリンクが一貫してに関係なく働くことになります。

Answer 5

私はこのilkの問題とすべての解決策をここで、他のSOスレッドでは解決できませんでした。最後に私はBFG repo cleanerを使用して、悪いフォルダ名を参照しているすべてのコミットを破棄しましたが、これは恐らく過剰なものでしたが、正常にrepoを修復しました。