問題タブ [git-rewrite-history]

約 2030 コミットのレポがあります。コミット 2000 年頃に、ファイルが変更されたため、サイズが約 20M から 1.2 GB に誤って移動しました。履歴を書き換えてこのファイルを削除することはできますが、コミット 2000 からのみ可能ですか? (このファイルの以前の履歴を失いたくない)

私はgit-filter-branchを考えていましたが、「コミットから」と伝える方法がわかりませんでした-可能ですか?

乾杯マイク

(今まで) git を使用して依存関係を格納するコードベースがあります。リポジトリ自体はここから入手できます(警告: 巨大です)。言うまでもなく、適切なサイズに縮小するには、リポジトリの履歴から依存関係を削除する必要があります。

まず、David Underhill の指示に従ってlib、履歴からディレクトリを削除しました。ただし、これを行った後でも、リポジトリはまだ 300M を超えています。発行git pruneしgit repackて助かりますが、それでも180Mを超えています。

肥大化したブロブを見つけようとして、発行しました

これらの結果:

105526b5d3d398b9989d88c2f9fc2d1dc96a85b8 blob 35685609 33600527 31978828 d296935e6ac5f3f58b50c789394c9769116e9c34 blob 35658016 33593241 112485744 50636f931180a32764edadd854968a971a083f8a blob 28360290 25897864 233390 b9e4dd37428e879a258f297b7f5bcfb9ba869695 blob 13108002 11640713 66661788 08d2720b2414aa07ce419b17d5f80c333c7313b7 blob 12551621 11124009 89231035 6197a478a461275a0396f20c28487e9ae619a5f9 blob 11975135 11058259 148211988 1 50636f931180a32764edadd854968a971a083f8a 549eb0c73776fd0ede27a2fcb03366f76f45a13c blob 9136086 8166649 166451273 5bc0a0f04a7004bc16cfab1c091c6b369fb74049 blob 9072616 8270262 80951514 741480238a6a6ce612cf089245dd46d6890fba9f blob 8858569 8080252 101294029 744226651c55b14c1aa8affb78fba4fdf02b577c blob 7412220 6766404 186825167

これは私が立ち往生しているところです。git showこれらの blob を確認すると、それらが jar ファイルに非常によく似ていることがわかりますが、なぜまだリポジトリにあるのかわかりません。

ファイル名を見つけるためのさまざまな試みは失敗しました。

git repack -a、git repack -ad、およびgit repack -Adすべて効果がないようです。

次のソースを使用して、リポジトリからいくつかの大きなファイルとディレクトリを消去しています:

http://dound.com/2009/04/git-forever-remove-files-or-folders-from-history/

git リポジトリがこれほど大きいのはなぜですか?

git filter-branch現在のブランチでのみ機能するようです-一度にすべてのブランチに適用する方法はありますか?

取り除きたい大きなブロブがあります。このソリューションを使用してファイルを削除したと思いました: http://dound.com/2009/04/git-forever-remove-files-or-folders-from-history/ (ファイルが削除されるよう-- --allに代わりに使用しましたHEADすべての支店から）

これを介してパックフォルダーを調べましたWhy is my git repository so big?

スクリプトgit-find-blobは、どのコミットがこのブロブを持っていますか?から取得されます。

しかし、何も見つかりません。

私のリポジトリからそれを取り除く方法はありますか?

ここで尋ねたのと同じ質問がありました:サブディレクトリに既存のリポジトリを含めるためのルート ディレクトリの新しい git リポジトリ

ここでこの回答に従いました：サブディレクトリに既存のリポジトリを含めるためのルートディレクトリの新しいgitリポジトリ

現在、gitk --allは 2 つの履歴を示しています。1 つは現在の で最高潮に達し、masterもう 1 つは という名前original/refs/heads/masterです。

この 2 番目の履歴が何であるか、レポから削除する方法がわかりません。リポジトリに 2 つの履歴は必要ありません。

どうすればそれを取り除くことができますか？

自分自身を再現するには:

ここで、元のポスターの問題があります。上記のリンクの回答を使用して、git リポジトリのルートを project-root に移動しましょう。

さて、私の現在の問題を見てください：

refs/original/heads/master関連するすべての履歴を削除するにはどうすればよいですか?

重複の可能性:
Git のコミット履歴から巨大なファイルを削除するには?

私は愚かなことをした。100MB のファイルをコミットしたとします。次に、これを見てこのファイルを削除し、再度コミットします。これは、ファイルを削除する通常の手順です。

しかし、この大きなファイルが保存されているため、履歴が重いという副作用があります (これが重い理由だと思います)。私はローカル git のみを使用しているため、どのサーバーでも同期しません。

このファイルを完全に削除してディスク容量を節約するにはどうすればよいですか?

私は3つのgitコミットを行いましたが、プッシュされていません。最新のものではない古いもの（ddc6859af44）と（47175e84c）を修正するにはどうすればよいですか？

master と gh-pages の 2 つのブランチを含むプロジェクトがあります。これらは基本的に 2 つの異なるプロジェクトであり、gh-pages プロジェクトはマスター プロジェクトに依存します (その逆はありません)。「master にはソース コードが含まれ、gh-pages にはそれらのソース ファイルからビルドされたバイナリが含まれる」と考えてください。定期的に、マスターに蓄積された変更を取得し、「マスター コミット xxxxxxxx と一致させる」というコミット メッセージを使用して、gh-pages ブランチに新しいコミットを行います。

これをしばらく行った後、gh-pages コミットの「マスター コミット xxxxxxxx と一致させる」が実際に git リポジトリの親として xxxxxxxx を持っていればいいことに気付きました。このように (悪い MSPaint アート):

リポジトリを上の 2 番目の画像のようにする方法はありますか? 新しいコミットを次のパターンにする方法を知っています: "git merge -s ours master" (そうでなければ空のコミットの親を設定します) の後に "git commit --amend adv550.z8" (ここで adv550.z8は、実際に変更されているバイナリ ファイルです)。しかし、git を使用すると、時間をさかのぼって古いコミットに新しい親を簡単に追加できますか?

ローカルリポジトリが正しく表示されたら、「git push -f」を実行して、Github リポジトリの現在の履歴を吹き飛ばしても構わないと思っています。問題は、ローカル リポジトリを正しく表示できるかどうかです。

数年後に追加して編集:最終的に、git 履歴をそのように見せる試みを断念しましgh-pagesた。私は、利益をゼロにするのは大変な作業だと判断しました。私の新しい習慣は、コミットを積極的に squash することgh-pagesです。私の場合、これらのコミット メッセージを保存することは実際には問題にならないからです。（これは「マスターコミットに合わせて...」という長い行であり、歴史的に興味深いものはありません。）ただし、これをもう一度行う必要がある場合は、次のような回答を聞きます。

かなり大きなリポジトリ（11 GB、900,000以上のファイル）があり、妥当な時間内に反復するのに問題があります。少しプロファイリングした後、本当のボトルネックはgitupdate-indexのようです。

そのため、ファイルのリストを取得するのに耐えられない日数になります。update-index操作を高速化する方法はありますか？

その価値については、Windows7でcygwinを実行しています。

編集：質問により多くの文脈を置くため。

大規模なリポジトリはSVNインポートからのものであり、リポジトリに含めるべきではない多数のバイナリが含まれています。ただし、コミット履歴とコミットログを保持したい。そのために、バイナリの内容をファイルハッシュに置き換えようとしています。これにより、リポジトリが圧縮され、履歴を保持できるようになります。

StackOverflow での「フラット化マージ」についての質問はほとんどなく、通常は「git rebase」という答えが返ってきます。ただし、これらの回答には、コミットの順序という重要なポイントが 1 つ欠けています。

6 月 1 日と 8 月 1 日にコミットされたブランチ A と、7 月 1 日にコミットされたブランチ B があるとします。 ）。B を A にマージすると、次の履歴が作成されます (git ログごと):

今、私が探しているのは、同じ結果を得る方法ですが、マージコミットはありません (したがって、その順序で基礎となる線形履歴があり、そうです、それはコミットを再親化することを意味します)。git rebase はここでは役に立ちません。それを使用すると、次の履歴が表示されます。

また

言い換えれば、git rebase は常に 1 つのブランチを別のブランチの上に積み重ねますが、著者のコミット日付でソートされたコミットを散在させるソリューションを探しています。

どうやら、単純なケースでは、git rebase -i を使用して手動で git rebase を後処理することで必要な調整を行うことができますが、これは大きな履歴では実用的ではないため、自動化されたコマンド/スクリプトを探しています。

使用事例？A と B が同じプロジェクトの異なる部分を表し、たまたま異なるリポジトリにあり、それらをマージしてそれを修正する時が来た場合、線形の履歴を実際の開発順序で展開することを望むのは自然なことです。