gitヒストリを書き直してファイルを修正する

Question

gitのヒストリーすべてから大量の不要なファイルを削除するには、filter-branchを使用して各コミットのインデックス（レポ内のファイルのリスト）を書き換えてファイルを追加しないようにすることができます。

git filter-branch --index-filter "git rm --cached --ignore-unmatch path/to/offending_file.wav" --tag-name-filter cat -- --all 

しかし、私は、ファイルを保持しますが、それはたくさん小さくしたい場合は（アイコンが誤って巨大な画像として保存した場合、例えば想像）。最初のファイルを確認してください。

HASH=`git hash-object -w /tmp/replacement.png` 

また、我々は次のように

FILE="path/to/icon.png" 

今すぐインデックスをフィルタリング交換したいファイルを注意し

まずgitののデータベースに交換用のファイルを追加します。私はこのアプローチを試してみました

git cat-file -e :"$FILE" 

インデックスから削除する場合：

git rm --cached "$FILE" 

最後に、同じファイル名で置き換えてください。

git update-index --add --cacheinfo "100644,$HASH,$FILE" 

はすべて一緒にそれを置く：

git filter-branch --index-filter "if git cat-file -e :$FILE ; then git rm --cached $FILE ; git update-index --add --cacheinfo 100644,$HASH,$FILE ; fi" --tag-name-filter cat -- --all 

これが動作しているようですし、すぎ怖いですすべてのエラーを印刷しません。しかし、どれくらい多くのgit gcとプルーンコマンドを使っても元のBLOBはリポジトリに存在しています。レポを新しい場所に複製しても、それはまだ存在します。

私は遠いリファレンスとが作成したoriginalの参照が元のファイルを依然として参照しているため、古いツリーを参照していると思われます。

私はこのようなハックでそれらのすべてを削除してみました：remotesため

for REF in `git show-ref | cut -c 42- | grep original` ; do git update-ref -d $REF ; done 

と同じですが、ブロブはまだそこにあります。

だから私の質問：

1. ブロブはごみが収集されない理由を確認する方法はありますか？私。グラフの親オブジェクトはそれを指していますか？
2. originalsのリファレンス（およびおそらくリモコン）（すべてのブランチとタグを含む）を削除する非ハックな方法はありますか？
3. 私には他に何かがありますか？

Answer 1

私はそれをやった！おもう。

追加手順は次のとおりです。まず、それはあなたが、それはまだ元のクローンへの参照を持っているので、私は、REFLOGをクリア最初のように、それは

git cat-file -t 949abcd.... 

[OK]をクリックして存在しているかどうかを確認することができますので、開始時に、あなたが望むブロブのハッシュに注意することをお勧めします：

git reflog expire --expire=now --all 

次に元のツリーへの参照があるため、元のリモートを削除しました。私はあなたがを押して新しいハッシュ（おそらくプッシュを強制する必要がある）場合は、このステップは不要で、ファイルは結局はGCされなければならないと思います。

git remote rm origin 

次に私は（filter-branchが作成する）original REFを除去しました。私はあまりハックのない方法を見つけませんでした：

for REF in `git show-ref | cut -c 42- | grep original` ; do git update-ref -d $REF ; done 

最後に、ガベージコレクト。 --aggressiveが必要かどうか分からないが、そうでなければgit gcだけがゴミ収集古いのために、安全のために--prune=nowがある。ブロブがなくなっていることを報告してgit cat-fileこれらすべての工程を経た後

git gc --aggressive --prune=now 

！私は結果を元に戻すことを実験していません（あなたがそれを再追加した後）、そして私は上記のステップのどれが必要であるかを100％確信していませんが、これは今まで働いていたようです。