私はここ数年 Git を使用しておりgit diff
、変更されたファイルの名前の前にa/
とb/
. 最終的には便利なユースケースに出くわすだろうと思っていましたが、今までは常に面倒で役に立たなかった.
それは何のために良いですか?これがデフォルトで有効になっているのはなぜですか? どのような状況で役立ちますか?
diff の man ページで説明されているように、ソースと宛先を区別するためのプレフィックスa/
をb/
表します。
実際には、次のオプションがあります。
--no-prefix
送信元または宛先のプレフィックスを表示しません。
--src-prefix=<prefix>
"a/" の代わりに、指定されたソース プレフィックスを表示します。
--dst-prefix=<prefix>
「b/」の代わりに指定された宛先プレフィックスを表示します
これらのディレクトリプレフィックスは、基本的に互換性のためにあり、適切なデフォルトとして選択されています。説明は次のとおりです。
git (およびその他のVCS ) が登場する前は、複数のファイルのパッチを作成するワークフローは、たとえば次のようになっていました。
asdf
ディレクトリにプロジェクトのソース コードがあるとしますasdf-source.latest
。asdf-source.new
、理想的には内部のファイルをハードリンクします)。asdf-source.new
、コードのコンパイルやテストなどを試すことができます。diff -r asdf-source.latest asdf-source.new >new_feature.patch
。出力も時間とともに進化しました。他のこととは別に、git はデフォルトで「統一された」出力を使用します。これは、diff の-u
パラメーターを使用して取得される可能性があります。これで、ディレクトリ名を使用して変更されたファイルへのパスがパッチに含まれていることがわかります。
パッチを適用する人 (またはビルド スクリプトなど) は、orpatch
の代わりに を使用します。コマンドが適切なファイルを見つけるためには、パッチのオプションを使用してディレクトリ名をパスから削除する必要があります (N は、削除するディレクトリ名とセパレータの数を示します)。上記の場合、使用されるコマンドは. これにより、パッチの作成者が自分のディレクトリ名を使用できるようになります。git apply
git am
-pN
patch -p1 <new_feature.patch
多くのパッチを使用してプロジェクトにパッチを適用するスクリプトに遭遇した場合 (通常、Linux ディストリビューションの安定したパッケージ バージョンのバックポートパッチに使用されます)、パッチの形式が異なる場合があります。コマンドはこれらpatch
の形式を適切に検出できますが、パス (削除するディレクトリの数) については少し難しくなります。それに関するいくつかの問題:
patch
探すのは危険です (別のファイルが見つかる可能性があるため)。したがって、適用可能なパッチを全員に送信してもらうpatch -p1
のが最も賢明な方法のようです。
git が作成されたとき、そのようなオプションに適切なデフォルト (ほとんどのプロジェクトの提出ガイドライン、主にカーネルと互換性があります) が採用されました。これにより、git を使用して、適切な形式のパッチをpatch
適用する人に送信したり、その逆を行ったりすることができます (git は、diff
作成されたパッチも処理できます)。特にプレフィックスとして「a」と「b」を使用すると、すべての機能を維持しながら、スペース (および帯域幅のごく一部) を節約できます。
git config diff.mnemonicprefix true
比較対象に応じて git が異なるプレフィックスを使用するように設定できます (詳細についてgit help config
は、を参照してください)。
出発地と目的地を区別するためです。より意味のあるものに変更することもできます。
--src-prefix=
<prefix>
Show the given source prefix instead of "a/".
--dst-prefix=
<prefix>
Show the given destination prefix instead of "b/".