From: Ben Knoble <ben.knoble@gmail.com>
Date: Sat, 21 Feb 2026 02:28:32 GMT
Subject: Re: [RFC] send-email: UTF-8 encoding in subject line
Message-ID: <5EDD26EE-51B6-4BE2-A7C7-E1E0991537E4@gmail.com>
In-Reply-To: <20260220145126.131651-1-shreyanshpaliwalcmsmn@gmail.com>


> Le 20 févr. 2026 à 09:51, Shreyansh Paliwal <shreyanshpaliwalcmsmn@gmail.com> a écrit :
> 
> Hi,
> 
> While using git send-email I ran into some confusion around the prompt that
> appears when any 8-bit (non-ASCII) content is detected.
> 
> When prompted with,
> 
>  Which 8bit encoding should I declare [UTF-8]? y
>  Are you sure you want to use <y> [y/N]? y

Yeah, that was a bit confusing for me until I got used to it. Maybe saying “[default: UTF-8]” would be a small and definite improvement?

> I initially assumed this was a yes/no style confirmation and answered "y",
> and ignored the 'which' part (this was due to my oversight). This resulted
> in the charset being set to "y", which later produced a subject line like,
> 
>  =?y?q?...?=
> 
> Mail clients like Gmail still displayed the message correctly, but the
> mailing list archive showed the raw encoded form[1].
> 
> Afterwards, I realized the prompt expects a charset name (e.g., "UTF-8")
> rather than a yes/no answer, and pressing enter would have selected the
> default (which is UTF-8).
> 
> I had also encountered this earlier when the non-ASCII character was in the
> message body rather than the subject, in that case the result appeared to
> work fine even with the mistaken input, which made the issue less obvious
> to me at first.
> 
> This made me wonder whether the current UX around the prompts or input
> validation could be improved in any way to reduce the chance of accidental
> input being interpreted as a charset name.
> 
> Best,
> Shreyansh
> 
> [1]- https://lore.kernel.org/git/20260219181154.66814-1-shreyanshpaliwalcmsmn@gmail.com/

Thanks for thinking on this; better that I never needed to get used to the oddity ;)