名前を変更したファイルのログをgitで本当に表示するにはどうすればよいですか？

私はgitに比較的慣れていません。以前にSubversionを使用しました。

ほとんどのグラフィカルgitフロントエンドとIDEプラグインは、ファイルの名前が変更されている場合、ファイルの履歴を表示できないようです。私が使うとき

git log --follow

コマンドラインでは、名前を変更してもログ全体を確認できます。

Linus Torvalds氏によると、-followスイッチは「SVN noob」を喜ばせるものであり、深刻なgitユーザーはそれを使用しません。

--followは完全なハックであり、親子関係や素敵なリビジョングラフなどについて何も知らなかった元SVNユーザーを満足させるだけのものです。

これは完全に基本的なものではありませんが、「-follow」の現在の実装は、実際に不可欠なものではなく、リビジョンウォーキングロジックにボルトで固定された迅速な前処理です。

それは文字通り、「実際のgit機能」としてではなく、「SVN noob」を満足させるものとして設計されました。アイデアは、全体像で問題の名前を変更するという（壊れた）思考の考え方から逃れることでした。

私の質問：名前が変更されたときに、ハードコアのgitユーザーがファイルの履歴をどのように取得しますか？これを行う「本当の」方法は何ですか？

Linusのポイントの背後にある一般的な動機は、ハードコアのgitユーザーが「ファイル」の履歴を気にしないということです。コンテンツは全体として意味のある履歴を持っているため、コンテンツをgitリポジトリに配置します。

ファイルの名前変更は、パス間を移動する「コンテンツ」の小さな特殊なケースです。gitユーザーが機能的に "pickaxe"を使用して追跡できるファイル間を移動する機能がある場合があります（例：）log -S。

その他の「パス」の変更には、ファイルの結合と分割が含まれます。gitは、名前の変更を検討しているファイルや、コピー（または名前の変更と削除）を検討しているファイルを実際には気にしません。ツリーのコンテンツ全体を追跡するだけです。

gitは、多くのバージョン管理システムが非常にファイル中心である「ツリー全体」の考え方を奨励しています。これが、gitが「ファイル名」を参照するよりも「パス」を参照することが多い理由です。

私はあなたが直面しているのとまったく同じ問題を抱えています。答えは出せませんが、Linusが2005年に書いたこのメールは読むことができると思います。これは非常に適切であり、問​​題の処理方法についてのヒントを与えるかもしれません。

…名前の変更が重要ではないため、内部的な理由で（つまり、効率的なデルタを許可するために）変更しない限り、名前の変更を追跡しようとするSCMは根本的に壊れていると私は主張しています。彼らはあなたを助けません、そして彼らはとにかくあなたが興味を持っていたものではありません。

重要なのは「これはどこから来たのか」を見つけることであり、gitアーキテクチャはそれを非常にうまく実行します。他のどこよりもはるかに優れています。…

私はそれがこのブログ投稿によって参照されていることを発見しました。これは、実行可能な解決策を見つけるのにも役立つかもしれません。

Linusはメッセージの中で、理想的なコンテンツ追跡システムを使用して、コードブロックが現在の形になった方法を見つける方法を説明しました。ファイル内の現在のコードブロックから開始し、履歴に戻ってファイルを変更したコミットを見つけます。次に、コミットの変更を検査して、関心のあるコードのブロックがそれによって変更されているかどうかを確認します。ファイルを変更するコミットは、関心のあるコードのブロックには触れず、その他の一部の部分のみに触れる可能性があるためです。ファイル。

コミットの前にコードのブロックがファイルに存在しないことがわかった場合は、コミットをより詳細に検査します。これは、次のような多くの考えられる状況の1つであることがわかります。

1. コミットは本当にコードのブロックを導入しました。コミットの作者は、あなたがその起源を探していたそのクールな機能の発明者（またはバグを導入した有罪者）でした。または
2. コードのブロックはファイルには存在しませんでしたが、同じファイルの5つのコピーが異なるファイルに存在し、すべてコミット後に消えました。commitの作成者は、単一のヘルパー関数を導入することにより、重複したコードをリファクタリングしました。または
3. （特殊なケースとして）コミットの前に、関心のあるコードのブロックが現在含まれているファイルは存在しませんでしたが、ほぼ同じ内容の別のファイルが存在し、関心のあるコードのブロックは、ファイル内の他のすべてのコンテンツと一緒に、当時存在していましたが、その他のファイルには存在していました。コミット後に消えました。コミットの作者はファイルに小さな変更を加えながら名前を変更しました。

gitでは、Linusの究極のコンテンツ追跡ツールはまだ完全に自動化された方法では存在しません。しかし、重要な成分のほとんどはすでに入手可能です。

これに関するあなたの進歩について私たちに投稿してください。

ほとんどのグラフィカルgitフロントエンドとIDEプラグインは、ファイルの名前が変更されている場合、ファイルの履歴を表示できないようです。

いくつかの人気のあるGit UIツールがこれをサポートするようになったことを喜んで知っています。数十のGit UIツールが利用できるので、それらすべてをリストすることはしませんが、例えば：

• SourceTreeのファイルログを表示すると、左下に「名前を変更したファイルを追跡する」チェックボックスがあります。
• TortoiseGitには、左下のログウィンドウに「名前変更に従う」チェックボックスがあります。

Git UIツールの詳細：

• http://git-scm.com/downloads/guis
• https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools

注：git 2.9（2016年6月）では、次の「バギー」な性質がかなり改善されますgit log --follow。

参照してくださいca4e3caをコミットすることで（2016年3月30日）SZEDERガーボル（szeder）。
^{（合併によりJunio C浜野- gitster-で26effb8コミット 2016年4月13日）}

diffcore：名前変更の検出中の同一ファイルの反復順序を修正

2つのパス ' dir/A/file'と ' dir/B/file'の内容が同じで、親ディレクトリの名前が変更された場合（例： ' git mv dir other-dir'） diffcore、次の正確な名前変更が報告されます。

renamed:    dir/B/file -> other-dir/A/file
renamed:    dir/A/file -> other-dir/B/file

（ここでの反転に注意してください：B/file -> A/file、およびA/file -> B/file）

技術的には間違っている、これはユーザーのために、だけでなく、リネーム情報、たとえば、「に基づいて判断しますgitのコマンドのためだけではなく、混乱されていないがgit log --follow other-dir/A/file」次の「dir/B/file名前の変更を過ぎて」を。

この動作はcommit v2.0.0-rc4〜8 ^ 2〜14（diffcore-rename.c：正確な名前変更の検索を簡素化、2013-11-14）の副作用です。ソースを格納するハッシュマップは同じバケットからエントリを返します。つまり、現在の宛先に一致するソース、LIFO順。
したがって、反復は最初に「other-dir/A/file」と「dir/B/file」を調べ、同一のコンテンツとベース名を見つけると、正確な名前変更を報告します。

Linuxでは、SmartGitとGitEyeが特定のファイルの履歴を追跡するときに名前の変更を追跡できることを確認しました。ただし、gitkやGitEyeとは異なり、SmartGitは個別のファイルビューとリポジトリビューを表示します（これにはディレクトリ構造が含まれますが、中に含まれるファイルのリストは含まれません）。