如何在 Powershell（与 bash）中正确生成和应用 git 补丁？

Question

请注意以下简短场景（这是在 Powershell 中）：

PS> git diff -U3 -r -M HEAD -- .\Metadata\LegacyTypeModules\xyz.Web.Main.draft.json | Out-File -Encoding ascii c:\temp\1.diff

PS> git apply --cached C:\temp\1.diff
error: patch failed: Metadata/LegacyTypeModules/xyz.Web.Main.draft.json:69
error: Metadata/LegacyTypeModules/xyz.Web.Main.draft.json: patch does not apply

这失败了，因为文件中的最后一行不以 CRLF 结尾：

但是，在 bash 中运行时，相同的命令可以工作：

$ git diff -U3 -r -M HEAD -- Metadata/LegacyTypeModules/xyz.Web.Main.draft.json > /c/Temp/2.diff

$ git apply --cached /c/Temp/2.diff

P11F70F@L-R910LPKW MINGW64 /c/xyz/tip (arch/1064933)

这两个补丁的区别是：

所以问题似乎发生了，因为 Powershell 使用 CRLF 终止通过 pipe 的每一行，而 bash 保留原始行结尾。

我理解为什么会发生这种情况 - Powershell 使用对象进行操作，并且对象是不包括EOL 字符的字符串。 在写入文件 Powershell 时，将对象转换为字符串（在字符串的情况下，转换是 nop）并使用默认的 EOL 序列来分隔行。

是不是说Powershell根本不能用在EOL敏感的场景？

Answer 1

您可以尝试使用join将 CRLF 替换为 unix EOL：

(git command arguments . . .) -join "`n" | out-file c:\temp\1.diff -NoNewline

Answer 2

标准差异（也称为补丁）以 LF 行结尾终止行。 那是因为这是 POSIX 为diff的 output 指定的内容。 所有行都必须包含一个 LF 行结尾。

当补丁中的 CR 在 LF 之前时，它被认为是要修补的内容的一部分。 因此，您的情况下的补丁可能不适用，因为旧内容被列为具有 CRLF 行结尾，而事实并非如此。

不幸的是，PowerShell 在这方面完全被破坏了，它的管道破坏了通过它们的数据。 对于任何类型的二进制数据尤其如此。 如果您使用任何设计为在 Unix 上运行的工具，例如 Git，则需要避免使用 PowerShell 的管道。

Answer 3

的确：

• PowerShell 总是将来自外部程序的 output解码为文本（使用[Console]::OutputEncoding ）

• 然后，当线路可用时，它通过管道逐行发送解码的 output。

• 文件输出 cmdlet（如Out-File然后总是使用平台原生换行符序列 - Windows 上的 CRLF - 在写入目标文件时终止每个（字符串化）输入 object（使用其默认字符编码（或通过-Encoding ），这在技术上与用于解码外部程序输出的编码无关）。

换句话说：从 PowerShell 7.2 开始， PowerShell 管道（和重定向）不支持通过 传递原始二进制数据- ZD3B7C913CD04EBFEC0E9EC302CB6FD58CZ 问题 #19中正在讨论未来的原始数据支持。

解决方法：

• 使用 LF 换行符 ( "`n" )手动连接和终止解码的 output 行，并将生成的多行字符串按原样 ( -NoNewLine ) 写入目标文件，如zdan 的有用答案所示。

• 在这个简单的情况下，最容易委托给cmd.exe /c ，因为cmd.exe的管道和重定向是原始字节管道：

cmd /c @'
git diff -U3 -r -M HEAD -- .\Metadata\LegacyTypeModules\xyz.Web.Main.draft.json > c:\temp\1.diff
'@

^{请注意使用here-string以提高任何嵌入式引用的可读性和易用性（此处不适用）。}