On Thu, Feb 05, 2015 at 11:29:07AM -0800, Junio C Hamano wrote: > Eric Blake <eblake@xxxxxxxxxx> 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 "/..../". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html