如何防止 git 格式补丁截断文件名

Question

I use git format-patch to share a list of patches for code review with my team members. The problem is I sometimes have quite a long commit message, and git format-patch truncates them when generating the files.

For example, I'd like to have a patch named 001-My-complete-message-bla-bla-bla.diff, but I get something like 001-My-comp.diff which doesn't help much understanding what there is inside.

I've searched everywhere about it for hours but I can't find any answer. It would be curious that no option exist to manage this.

Thanks in advance.

Answer 1

9 years later, there seems to be a solution (compared to my old answer ) with Git 2.30 (Q1 2021).

The maximum length of output filenames " git format-patch " ^{( man )} creates has become configurable (used to be capped at 64).

See commit 3baf58b (06 Nov 2020) by Junio C Hamano ( gitster ) .
^{(Merged by Junio C Hamano -- gitster -- in commit 473c622 , 21 Nov 2020)}

format-patch : make output filename configurable

For the past 15 years, we've used the hardcoded 64 as the length limit of the filename of the output from the " git format-patch " ^{( man )} command.

Since the value is shorter than the 80-column terminal, it could grow without line wrapping a bit.
At the same time, since the value is longer than half of the 80-column terminal, we could fit two or more of them in " ls " output on such a terminal if we allowed to lower it.

Introduce a new command line option --filename-max-length=<n> and a new configuration variable format.filenameMaxLength to override the hardcoded default.

While we are at it, remove a check that the name of output directory does not exceed PATH_MAX---this check is pointless in that by the time control reaches the function, the caller would already have done an equivalent of " mkdir -p ", so if the system does not like an overly long directory name, the control wouldn't have reached here, and otherwise, we know that the system allowed the output directory to exist.
In the worst case, we will get an error when we try to open the output file and handle the error correctly anyway.

git config now includes in its man page :

format.filenameMaxLength

The maximum length of the output filenames generated by the format-patch command; defaults to 64.
Can be overridden by the --filename-max-length=<n> command line option.

git format-patch now includes in its man page :

--filename-max-length=<n>

Instead of the standard 64 bytes, chomp the generated output filenames at around ' <n> ' bytes (too short a value will be silently raised to a reasonable length).
Defaults to the value of the format.filenameMaxLength configuration variable, or 64 if unconfigured.

Answer 2

If there is no solution on the format-patch front, one possible workaround would be to make an incremental bundle , which:

• would result in only one file (instead of many for the patches )
• would support a kind of git log with git bundle verify : it will list the commits included in that bundle, with their (complete!) log message

---

Abizern suggests a temporary branch for applying and examining those patches before merging back to their own branch.
That is a possibility, but still, log messages are nice;)