私はWindowsユーザーではないので、一粒の塩で答えてください。Windows PowerShellクックブックによると、PowerShellはの出力を前処理しgit diff
、行に分割します。Cmdletのドキュメントは、パラメータなしの場合と同じOut-File
であることを示唆しています。このコメントは、PowerShellのドキュメントにもあります。>
| Out-File
Out-Fileコマンドレットを使用した結果は、従来の出力リダイレクトに慣れている場合は期待したものとは異なる場合があります。その動作を理解するには、Out-Fileコマンドレットが動作するコンテキストに注意する必要があります。
デフォルトでは、Out-FileコマンドレットはUnicodeファイルを作成します。これは長期的には最良のデフォルトですが、ASCIIファイルを期待するツールがデフォルトの出力形式で正しく機能しないことを意味します。Encodingパラメータを使用して、デフォルトの出力形式をASCIIに変更できます。
[...]
出力ファイルは、ファイルの内容をコンソール出力のようにフォーマットします。これにより、ほとんどの状況でコンソールウィンドウの場合と同じように、出力が切り捨てられます。[...]
行の折り返しを画面の幅に一致させない出力を取得するには、Widthパラメーターを使用して行の幅を指定できます。
したがって、文字エンコードを選択するのは明らかにGitではなく、Out-File
です。これは、a)PowerShellリダイレクトは実際にはテキストにのみ使用する必要があり、b)
| Out-File -encoding ASCII -Width 2147483647 my.patch
エンコーディングの問題を回避します。ただし、これでもWindowsとUnixの行末の問題は解決されません。行末の変換を行うためのコマンドレット(PowerShell Community Extensionsを参照)があります。
ただし、このすべての再コーディングによって、パッチに対する信頼性が向上するわけではありません(パッチ自体にはエンコードがありませんが、バイトの文字列にすぎません)。前述のクックブックには、コマンドの出力を変更せずにリダイレクトするために使用できるスクリプトInvoke-BinaryProcessが含まれています。
この問題全体を回避するには、のgit format-patch
代わりにを使用することもできますgit diff
。format-patch
(stdoutではなく)ファイルに直接書き込むため、その出力は再コード化されません。ただし、パッチはコミットからのみ作成でき、任意の差分は作成できません。
format-patch
コミット範囲(例master^10..master^5
)または単一のコミット(例:X、X..HEADを意味する)を取り、NNNN-SUBJECT.patchの形式のパッチファイルを作成します。ここで、NNNNは増加する4桁の数字であり、件名は(マングル)です。パッチの件名。出力ディレクトリは。で指定できます-o
。