# Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support 7 messages from 2015-02-05 to 2015-02-18. Participants: Eric Blake, Junio C Hamano, Jeff King. Thread: https://gitlist.dev/t/38510 ## Eric Blake, 2015-02-05 15:25 Subject: Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support Message-ID: <54D38B73.4060803@redhat.com> URL: https://gitlist.dev/e/54D38B73.4060803%40redhat.com In-Reply-To: <20150205114914.GA10126@stefanha-thinkpad.redhat.com> ``` [adding git list to cc] On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote: > On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote: >> This series is based on the previous patchset from Chen Fan: >> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html > > This email has an invalid charset: > Content-Type: text/plain; charset="y" > > I guess you entered "y" when asked how the message was encoded. > > Please don't do that, it means we can only guess at the charset. In the past, people made a similar problem when 'git send-email' was asking if a message was in-reply-to something else (the number of messages incorrectly threaded to a message-id of 'y' or 'n' was evidence of the poor quality of the question). git.git commit 51bbccfd1b4a corrected that problem. Sounds like charset encoding is another case where the interactive parser should be taught to balk at nonsense encoding answers? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ``` ## Junio C Hamano, 2015-02-05 19:29 Subject: Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support Message-ID: URL: https://gitlist.dev/e/xmqqiofgkvi4.fsf%40gitster.dls.corp.google.com In-Reply-To: <54D38B73.4060803@redhat.com> ``` Eric Blake writes: > On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote: >> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote: >>> This series is based on the previous patchset from Chen Fan: >>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html >> >> This email has an invalid charset: >> Content-Type: text/plain; charset="y" >> >> I guess you entered "y" when asked how the message was encoded. >> >> Please don't do that, it means we can only guess at the charset. > > In the past, people made a similar problem when 'git send-email' was > asking if a message was in-reply-to something else (the number of > messages incorrectly threaded to a message-id of 'y' or 'n' was evidence > of the poor quality of the question). git.git commit 51bbccfd1b4a > corrected that problem. Sounds like charset encoding is another case > where the interactive parser should be taught to balk at nonsense > encoding answers? I think I answered this in $gmane/263354; care to come up with a plausible valid_re? It is inpractical to attempt to cover all valid charset names, so whatever you do I'd imagine you would want to pass the confirm_only parameter set to true. ``` ## Jeff King, 2015-02-05 19:57 Subject: Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support Message-ID: <20150205195758.GC15326@peff.net> URL: https://gitlist.dev/e/20150205195758.GC15326%40peff.net In-Reply-To: ``` On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote: > Eric Blake writes: > > > On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote: > >> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote: > >>> This series is based on the previous patchset from Chen Fan: > >>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html > >> > >> This email has an invalid charset: > >> Content-Type: text/plain; charset="y" > >> > >> I guess you entered "y" when asked how the message was encoded. > >> > >> Please don't do that, it means we can only guess at the charset. > > > > In the past, people made a similar problem when 'git send-email' was > > asking if a message was in-reply-to something else (the number of > > messages incorrectly threaded to a message-id of 'y' or 'n' was evidence > > of the poor quality of the question). git.git commit 51bbccfd1b4a > > corrected that problem. Sounds like charset encoding is another case > > where the interactive parser should be taught to balk at nonsense > > encoding answers? > > I think I answered this in $gmane/263354; care to come up with a > plausible valid_re? It is inpractical to attempt to cover all valid > charset names, so whatever you do I'd imagine you would want to pass > the confirm_only parameter set to true. Would "length() > 1" be enough[1]? Or are people really typing "yes" and not just "y"? I cannot imagine a charset name that is smaller than two characters. It may be that there are none smaller than 4, and we could cut it off there. Googling around for some lists of common charsets, it seems like that might be plausible (but not any larger; "big5" is 4 characters, and people may spell "utf8" without the hyphen). -Peff [1] Of course, to match the existing regex code, we may want to spell this as "/../" or "/..../". ``` ## Junio C Hamano, 2015-02-05 20:17 Subject: Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support Message-ID: URL: https://gitlist.dev/e/xmqq61bgkt9w.fsf%40gitster.dls.corp.google.com In-Reply-To: <20150205195758.GC15326@peff.net> ``` Jeff King writes: > On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote: > >> Eric Blake writes: >> >> > On 02/05/2015 04:49 AM, Stefan Hajnoczi wrote: >> >> On Wed, Jan 14, 2015 at 03:27:23PM +0800, Zhu Guihua wrote: >> >>> This series is based on the previous patchset from Chen Fan: >> >>> https://lists.nongnu.org/archive/html/qemu-devel/2014-05/msg02360.html >> >> >> >> This email has an invalid charset: >> >> Content-Type: text/plain; charset="y" >> >> >> >> I guess you entered "y" when asked how the message was encoded. >> >> >> >> Please don't do that, it means we can only guess at the charset. >> > >> > In the past, people made a similar problem when 'git send-email' was >> > asking if a message was in-reply-to something else (the number of >> > messages incorrectly threaded to a message-id of 'y' or 'n' was evidence >> > of the poor quality of the question). git.git commit 51bbccfd1b4a >> > corrected that problem. Sounds like charset encoding is another case >> > where the interactive parser should be taught to balk at nonsense >> > encoding answers? >> >> I think I answered this in $gmane/263354; care to come up with a >> plausible valid_re? It is inpractical to attempt to cover all valid >> charset names, so whatever you do I'd imagine you would want to pass >> the confirm_only parameter set to true. > > Would "length() > 1" be enough[1]? Or are people really typing "yes" and > not just "y"? > > I cannot imagine a charset name that is smaller than two characters. It > may be that there are none smaller than 4, and we could cut it off > there. Googling around for some lists of common charsets, it seems like > that might be plausible (but not any larger; "big5" is 4 characters, and > people may spell "utf8" without the hyphen). > > -Peff > > [1] Of course, to match the existing regex code, we may want to spell > this as "/../" or "/..../". Perhaps. Just in case there were shorter ones, something like this with confirm_only to allow them to say "Yes, I do mean 'xx'"? git-send-email.perl | 1 + 1 file changed, 1 insertion(+) diff --git a/git-send-email.perl b/git-send-email.perl index 3092ab3..848f176 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -752,6 +752,7 @@ sub file_declares_8bit_cte { print " $f\n"; } $auto_8bit_encoding = ask("Which 8bit encoding should I declare [UTF-8]? ", + valid_re => qr/.{4}/, confirm_only => 1, default => "UTF-8"); } ``` ## Jeff King, 2015-02-06 19:33 Subject: Re: [Qemu-devel] [PATCH v3 0/7] cpu: add device_add foo-x86_64-cpu support Message-ID: <20150206193349.GB4220@peff.net> URL: https://gitlist.dev/e/20150206193349.GB4220%40peff.net In-Reply-To: ``` On Thu, Feb 05, 2015 at 12:17:15PM -0800, Junio C Hamano wrote: > > Would "length() > 1" be enough[1]? Or are people really typing "yes" and > > not just "y"? > > > > I cannot imagine a charset name that is smaller than two characters. It > > may be that there are none smaller than 4, and we could cut it off > > there. Googling around for some lists of common charsets, it seems like > > that might be plausible (but not any larger; "big5" is 4 characters, and > > people may spell "utf8" without the hyphen). > > > > -Peff > > > > [1] Of course, to match the existing regex code, we may want to spell > > this as "/../" or "/..../". > > Perhaps. Just in case there were shorter ones, something like this > with confirm_only to allow them to say "Yes, I do mean 'xx'"? > > git-send-email.perl | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/git-send-email.perl b/git-send-email.perl > index 3092ab3..848f176 100755 > --- a/git-send-email.perl > +++ b/git-send-email.perl > @@ -752,6 +752,7 @@ sub file_declares_8bit_cte { > print " $f\n"; > } > $auto_8bit_encoding = ask("Which 8bit encoding should I declare [UTF-8]? ", > + valid_re => qr/.{4}/, confirm_only => 1, > default => "UTF-8"); > } Yes, I think leaving an escape hatch is a good idea, just in case. -Peff ``` ## Junio C Hamano, 2015-02-16 22:34 Subject: [PATCH] send-email: ask confirmation if given encoding name is very short Message-ID: URL: https://gitlist.dev/e/xmqqiof14hax.fsf_-_%40gitster.dls.corp.google.com In-Reply-To: <20150206193349.GB4220@peff.net> ``` Sometimes people respond "y" (or "yes") when asked this question: Which 8bit encoding should I declare [UTF-8]? We already have a mechanism to avoid accepting a mistyped e-mail address (we ask to confirm when the given address lacks "@" in it); reuse it to trigger the same confirmation when given a very short answer. As a typical charset name is probably at least 4 chars or longer (e.g. "UTF8" spelled without the dash, or "Big5"), this would prevent such a mistake. Signed-off-by: Junio C Hamano --- * Will mark to be merged to 'next'. git-send-email.perl | 1 + 1 file changed, 1 insertion(+) diff --git a/git-send-email.perl b/git-send-email.perl index fdb0029..eb32371 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -733,6 +733,7 @@ sub file_declares_8bit_cte { print " $f\n"; } $auto_8bit_encoding = ask("Which 8bit encoding should I declare [UTF-8]? ", + valid_re => qr/.{4}/, confirm_only => 1, default => "UTF-8"); } -- 2.3.0-282-gf18c841 ``` ## Jeff King, 2015-02-18 18:58 Subject: Re: [PATCH] send-email: ask confirmation if given encoding name is very short Message-ID: <20150218185812.GC7257@peff.net> URL: https://gitlist.dev/e/20150218185812.GC7257%40peff.net In-Reply-To: ``` On Mon, Feb 16, 2015 at 02:34:14PM -0800, Junio C Hamano wrote: > Sometimes people respond "y" (or "yes") when asked > this question: > > Which 8bit encoding should I declare [UTF-8]? > > We already have a mechanism to avoid accepting a mistyped e-mail > address (we ask to confirm when the given address lacks "@" in it); > reuse it to trigger the same confirmation when given a very short > answer. As a typical charset name is probably at least 4 chars or > longer (e.g. "UTF8" spelled without the dash, or "Big5"), this would > prevent such a mistake. > > Signed-off-by: Junio C Hamano > --- > > * Will mark to be merged to 'next'. Probably belated review, but this looks good to me. -Peff ```