如何防止git format-patch截断文件名

Question

我使用git format-patch与我的团队成员共享代码审查的补丁列表。问题是我有时会提交相当长的提交消息，并且git format-patch会在生成文件时截断它们。

例如，我想要一个名为001-My-complete-message-bla-bla-bla.diff的补丁，但我得到类似于001-My-comp.diff的东西，这对于理解不大里面有什么。

我几个小时都在搜索它，但我找不到任何答案。很遗憾没有选择来管理这个。

提前致谢。

Answer 1

如果格式补丁方面没有解决方案，一种可能的解决方法是制作 incremental bundle ，其中：

• 只会产生一个文件（而不是many for the patches）
• 会支持git log git bundle verify {{1}}：它将列出该捆绑包中包含的提交及其（完整！）日志消息

---

Abizern建议在合并回自己的分支之前应用和检查这些补丁的临时分支 这是一种可能性，但是，日志消息仍然很好;）

Answer 2

9年后，似乎有了Git 2.30（2021年第一季度）的解决方案（与my old answer相比）。

创建的输出文件名“ git format-patch” ^（man）的最大长度已可配置（以前限制为64）。

请参见commit 3baf58b的Junio C Hamano (gitster)（2020年11月6日）。
^{（由Junio C Hamano -- gitster --在commit 473c622中合并，2020年11月21日）}

format-patch：使输出文件名可配置

在过去15年中，我们将硬编码64用作“ git format-patch” ^（man）命令的输出文件名的长度限制

由于该值比80列终端短，因此它可能会增加而无需换行。
同时，由于该值大于80列终端的一半，因此如果允许降低该值，我们可以在该终端的“ ls”输出中容纳其中两个或多个。

引入新的命令行选项--filename-max-length=<n>和新的配置变量format.filenameMaxLength，以覆盖硬编码的默认值。

在此过程中，删除检查输出目录名称不超过PATH_MAX---this的检查是没有意义的，因为在控件到达函数时，调用者将已经完成了“ { {1}}”，因此，如果系统不喜欢目录名过长，则控件将不会到达此处，否则，我们知道系统允许输出目录存在。
在最坏的情况下，尝试打开输出文件并仍然正确处理错误时，我们会收到错误消息。

mkdir -p现在包含在其man page中：

git config

由...生成的输出文件名的最大长度 format.filenameMaxLength命令；默认为64。
可以被format-patch命令行选项覆盖。

--filename-max-length=<n>现在包含在其man page中：

git format-patch

不是标准的64个字节，而是压缩生成的输出 文件名大约为“ {--filename-max-length=<n>”字节（太短的值将是 默默地提高到合理的长度。
默认为<n>配置的值 变量，如果未配置，则为64。