我不是 Windows 用户,所以对我的回答持保留态度。根据Windows PowerShell Cookbook,PowerShell 对 的输出进行预处理git diff
,将其分成几行。Cmdlet的文档Out-File
表明,这与没有参数>
的情况相同。| Out-File
我们还在PowerShell 文档中找到了这条评论:
如果您习惯于传统的输出重定向,则使用 Out-File cmdlet 的结果可能不是您所期望的。要了解其行为,您必须了解 Out-File cmdlet 运行的上下文。
默认情况下,Out-File cmdlet 创建一个 Unicode 文件。从长远来看,这是最好的默认设置,但这意味着需要 ASCII 文件的工具无法在默认输出格式下正常工作。您可以使用 Encoding 参数将默认输出格式更改为 ASCII:
[...]
Out-file 将文件内容格式化为类似于控制台输出。这会导致输出被截断,就像在大多数情况下在控制台窗口中一样。[...]
要获得不强制换行以匹配屏幕宽度的输出,可以使用 Width 参数指定线宽。
所以,显然不是 Git 选择了字符编码,而是Out-File
. 这表明 a) PowerShell 重定向真的应该只用于文本和 b)
| Out-File -encoding ASCII -Width 2147483647 my.patch
将避免编码问题。但是,这仍然不能解决 Windows 与 Unix 行尾的问题。有 Cmdlet(请参阅PowerShell Community Extensions)来转换行尾。
然而,所有这些重新编码并没有增加我对补丁的信心(它本身没有编码,而只是一串字节)。上述Cookbook包含一个脚本 Invoke-BinaryProcess,可用于重定向未修改的命令的输出。
为了回避整个问题,另一种方法是使用git format-patch
而不是git diff
. format-patch
直接写入文件(而不是标准输出),因此不会重新编码其输出。但是,它只能从提交创建补丁,而不是任意差异。
format-patch
接受一个提交范围(例如master^10..master^5
)或单个提交(例如 X,表示 X..HEAD)并创建 NNNN-SUBJECT.patch 形式的补丁文件,其中 NNNN 是一个递增的 4 位数字,主题是(损坏的)补丁的主题。可以使用 指定输出目录-o
。