"Robin Jarry" <robin@xxxxxxxx> writes:
> Thinking again about that. The probability that a file path name
> generated by git-format-patch would contain LF is close to zero.
Close to zero is very different from absolutely zero, and in the
case of format-patch generated patches, I think it is absolutely
zero. At least, that was the case back when I designed and
implemented it, and I do not think I accepted a patch to break it
over the years.
But "git send-email" can be fed a list of files and even a directory
(and enumerate files in it). The filenames are under end-users'
control in this case, so "close to zero" has absolutely no relevance.
If the end user means to feed you such a file, they can do so 100%
of the time.
If we support such a file is a different issue. A good rule of
thumb to decide if it is reasonable is to see if the main command
already works with such filenames, e.g.
$ git format-patch -2
0001-foo.txt
0002-bar.txt
$ mv 0001-foo.txt '0001-fo
> o.txt'
$ mkdir dir
$ mv 000[12]*.txt dir/.
may prepare two patch files that can be sent via send-email. One
file (the first one) is deliberately given a filename with LF in
it. Does send-email work on it correctly if you did e.g.
$ git send-email dir/000[12]*.txt
or something silly like
$ git send-email dir
or does it already choke on the first file because of the filename?
