From: Junio C Hamano <gitster@pobox.com>
To: "Robin Jarry" <robin@jarry.cc>
Cc: <phillip.wood@dunelm.org.uk>, <git@vger.kernel.org>,
"Tim Culverhouse" <tim@timculverhouse.com>,
"Nicolas Dichtel" <nicolas.dichtel@6wind.com>,
"Bagas Sanjaya" <bagasdotme@gmail.com>,
"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH RESEND] hooks: add sendemail-validate-series
Date: Mon, 03 Apr 2023 15:52:04 -0700 [thread overview]
Message-ID: <xmqq7cus4m0b.fsf@gitster.g> (raw)
In-Reply-To: <CRNH5FOB91JE.14CZEA494X002@ringo> (Robin Jarry's message of "Tue, 04 Apr 2023 00:29:47 +0200")
"Robin Jarry" <robin@jarry.cc> 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?
next prev parent reply other threads:[~2023-04-03 22:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-02 18:56 [PATCH RESEND] hooks: add sendemail-validate-series Robin Jarry
2023-04-03 0:17 ` Eric Sunshine
2023-04-03 14:09 ` Phillip Wood
2023-04-03 14:32 ` Robin Jarry
2023-04-03 15:20 ` Phillip Wood
2023-04-03 15:42 ` Junio C Hamano
2023-04-03 17:25 ` Robin Jarry
2023-04-03 22:29 ` Robin Jarry
2023-04-03 22:52 ` Junio C Hamano [this message]
2023-04-03 22:59 ` Robin Jarry
2023-04-04 20:14 ` Junio C Hamano
2023-04-05 8:31 ` Robin Jarry
2023-04-05 21:49 ` Junio C Hamano
2023-04-05 23:13 ` [PATCH v2] " Robin Jarry
2023-04-06 8:56 ` Ævar Arnfjörð Bjarmason
2023-04-11 9:58 ` Phillip Wood
2023-04-11 10:39 ` Robin Jarry
2023-04-11 15:58 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq7cus4m0b.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=bagasdotme@gmail.com \
--cc=git@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=robin@jarry.cc \
--cc=sunshine@sunshineco.com \
--cc=tim@timculverhouse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.