削除した行を「git blame」するにはどうすればよいですか？

git blame変更および追加された行には最適ですが、特定の以前のコミットに存在していた行が最終的に削除された場合、どうすれば見つけられますか。と思っていますがbisect、もっと便利なものを期待していました。

（あなたが尋ねる前に：この場合、私はa git log -pを実行してコード行を検索し、（a）ある馬鹿が前のコミットで重要な行を削除したばかりで、（b）私はその馬鹿でした。）

行の内容がわかっている場合、これは次の場合の理想的な使用例です。

git log -S <string> path/to/file

これは、その文字列のインスタンスを導入または削除するコミットを示しています。-G<regex>正規表現で同じことをするものもあります！詳細についてman git-logは、-Gおよび-Sオプション、またはツルハシ（これらの機能のわかりやすい名前）を参照して検索してください。

この-Sオプションは、実際にはgit-blameマンページのヘッダーの説明セクションにも記載されていgit log -S...ます。ここでは、を使用した例が示されています。

あなたが本当に欲しいのは

git blame --reverse START..END filename

マンページから：

履歴を後方ではなく前方に移動します。行が表示されたリビジョンを表示する代わりに、行が存在した最後のリビジョンを表示します。これには、START..ENDのような一連のリビジョンが必要です。

を使用git blame reverseすると、行が表示された最後のコミットを見つけることができます。その後に続くコミットを取得する必要があります。

次のコマンドを使用して、リバースされたgitログを表示できます。表示される最初のコミットはその行が最後に表示される時間であり、次のコミットは変更または削除されたときです。

git log --reverse --ancestry-path COMMIT^..master

カスカベルの答えを完成させるために：

git log --full-history -S <string> path/to/file

ここで述べたのと同じ問題がありましたが、ブランチからのマージコミットが元に戻されてマージされ、問題の行を効果的に削除したため、行が欠落していることがわかりました。--full-historyこれらのコミットをスキップフラグ防止。

gitの責任の--reverseはあなたを得ることができます近い行が削除されている場所へ。しかし、実際にはその行が削除されたリビジョンを指しているわけではありません。行が存在した最後のリビジョンを指します。次に、次のリビジョンがプレーンコミットである場合、幸運であり、削除リビジョンを取得しました。OTOH、次のリビジョンがマージコミットである場合、物事は少しワイルドになる可能性があります。

difflameを作成するための取り組みの一環として、私はこの非常に問題に取り組んだので、既にボックスにPythonがインストールされていて、それを試してみるつもりなら、それ以上待たずにそれがどうなるかを知らせてください。

https://github.com/eantoranz/difflame

マージコミットに隠された変更について

マージコミットでは、Gitログ出力から変更が自動的に非表示になります。つるはしと逆責めの両方で変更は見つかりませんでした。だから私が欲しかった行が追加されて後で削除され、それを削除したマージを見つけたかったのです。ファイルgit log -p -- path/file履歴には、追加されていることが示されているだけです。これが私が見つけた最良の方法です：

git log -p -U9999 -- path/file

変更を検索してから、「^ commit」を逆方向に検索します。最初の「^ commit」は、ファイルに最後にその行があったコミットです。2番目の「^ commit」は非表示になった後です。2番目のコミットはそれを削除したものかもしれません。これ-U9999は、ファイルがすべて最大9999行であると想定して、（ファイルが変更されるたびに）ファイルの内容全体を表示するためのものです。

ブルートフォースを介して関連するマージを検索します（可能な各マージコミットを最初の親と比較し、大量のコミットに対して実行します）

git log --merges --pretty=format:"git diff %h^...%h | grep target_text" HEAD ^$(git merge-base A B) | sh -v 2>&1 | less

（リビジョンフィルターをさらに制限してみましたが、問題が発生したためお勧めしません。探していた追加/削除の変更は、異なる時点でマージされた異なるブランチにあり、A ... Bには含まれていませんでした変更が実際にメインラインにマージされたとき。）

次の2つのコミットを使用してGitツリーを表示します（複雑なGit履歴の多くを削除します）。

git log --graph --oneline A B ^$(git merge-base A B) （Aは上記の最初のコミット、Bは上記の2番目のコミットです）

Aの履歴とBの履歴からAとBの両方の履歴を差し引いたものを表示します。

代替バージョン（通常のGit履歴ツリーではなく、より直線的にパスを表示するように見えますが、通常のgit履歴ツリーを好みます）：

git log --graph --oneline A...B

2つのドットではなく3つ-3つのドットは「r1 r2 --not $（git merge-base --all r1 r2）を意味します。これは、r1（左側）またはr2（右側）のいずれかから到達可能なコミットのセットです。サイド）、しかし両方からではありません。」-ソース： "man gitrevisions"