Re: [PATCH RESEND] hooks: add sendemail-validate-series
- From
Robin Jarry <robin@jarry.cc>
- Date
- Apr 3, 2023, 22:59 UTC
- Message-ID
- <CRNHSC3H2B6C.UCSDE4Y6ET4A@ringo>
- In-Reply-To
- <xmqq7cus4m0b.fsf@gitster.g>
Junio C Hamano, Apr 04, 2023 at 00:52:
Show 11 quoted lines
> 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
Show 23 quoted lines
> 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...