Re: [PATCH] send-email: add extra safetly in address sanitazion
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 5, 2012, 21:12 UTC
- Message-ID
- <7v4nv5gf2n.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CAMP44s0xfbxLs_r81ppO9hYf3ML_gaYCaW3TKpLM=BjfaM8vHg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
Show 10 quoted lines
> On Sat, Feb 4, 2012 at 5:10 PM, Felipe Contreras > <felipe.contreras@gmail.com> wrote: >> Otherwise, 'git send-email' would be happy to do: >> >> % git send-email --to '<foo@bar.com>>' >> >> And use '<foo@bar.com>>' in the headers. > > Er, actually that's not correct: '<foo@bar.com>>' will remain the > same, but 'Foo <foo@bar.com>>' will be sanitized.
I suspect that this "Er" is merely a sympotom of a larger issue in the approach taken by this patch. The code takes a potentially malformed input, and applies a rewrite logic without telling the user what it is doing. If the rewrite logic is perfect, that may be OK, but if not, the logic to rewrite may or may not trigger, or when it triggers it may or may not produce a correct result, and it all depends on the nature of breakage in the input.
Wouldn't a better approach to detect problem on the input side and reject a wrong one by erroring out, so that the user has a chance to fix?