Junio C Hamano, Apr 04, 2023 at 00:52: > 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. Ok that's a fair point. Even though I am having a hard time believing someone would do such a thing :D > 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? It seems to work with both. I guess, NUL bytes separation it is then...
