Ævar Arnfjörð Bjarmason writes:
> Ripping out Error.pm for our few internal callers is one thing, trying
> to maintain bugwards compatibility with how it throws exceptions for
> users expecting Error.pm objects is another. I think at that point it's
> easier to just stay with

Ævar Arnfjörð Bjarmason writes:
> My "Makefile: replace perl/Makefile.PL with simple make rules" currently
> cooking in pu changes that so that:
>
> * We always at runtime test for the system CPAN module.
>
> * In the case of Error.pm we happen to ship a fallback, in the case

Thomas Adam writes:
> Hi,
>
> On Mon, Dec 11, 2017 at 08:46:46PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> I.e. we'd just ship a copy of Email::Valid and Mail::Address in
>> perl/Git/FromCPAN/, use a wrapper to load them, and then we wouldn't
>> need to if/else this at the

On Tue, Dec 12 2017, Thomas Adam jotted:
> Hi,
>
> On Mon, Dec 11, 2017 at 08:46:46PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> I.e. we'd just ship a copy of Email::Valid and Mail::Address in
>> perl/Git/FromCPAN/, use a wrapper to load them, and then we wouldn't
>> need to if/else this at the

Hi,
On Mon, Dec 11, 2017 at 08:46:46PM +0100, Ævar Arnfjörð Bjarmason wrote:
> I.e. we'd just ship a copy of Email::Valid and Mail::Address in
> perl/Git/FromCPAN/, use a wrapper to load them, and then we wouldn't
> need to if/else this at the code level, just always use the module,
> and it

On Mon, Dec 11, 2017 at 6:26 PM, Thomas Adam wrote:
> On Mon, Dec 11, 2017 at 05:13:53PM +, Alex Bennée wrote:
>> So have we come to a consensus about the best solution here?
>>
>> I'm perfectly happy to send a reversion patch because to be honest
>> hacking on a bunch of

On Mon, Dec 11, 2017 at 05:13:53PM +, Alex Bennée wrote:
> So have we come to a consensus about the best solution here?
>
> I'm perfectly happy to send a reversion patch because to be honest
> hacking on a bunch of perl to handle special mail cases is not my idea
> of fun spare time hacking

Junio C Hamano writes:
> Thomas Adam writes:
>
>> Trying to come up with a reinvention of regexps for email addresses is asking
>> for trouble, not to mention a crappy rod for your own back. Don't do that.
>> This is why people use Mail::Address.
>>
>>

Matthieu Moy writes:
> My point in cc907506 ("send-email: don't use Mail::Address, even if
> available", 2017-08-23) was not that Mail::Address was bad, but that
> changing our behavior depending on whether it was there or not was
> really bad. For example, the issue

Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Was there any reason why Mail::Address was _inadequate_?
>
> I think the main reason was that Mail::Address is not a standard perl
> module, and not relying on it avoided one external dependency.

Junio C Hamano writes:
> Was there any reason why Mail::Address was _inadequate_?
I think the main reason was that Mail::Address is not a standard perl
module, and not relying on it avoided one external dependency. AFAIK, we
don't really have a good way to deal with Perl

Thomas Adam writes:
> Trying to come up with a reinvention of regexps for email addresses is asking
> for trouble, not to mention a crappy rod for your own back. Don't do that.
> This is why people use Mail::Address.
>
>

On Tue, Nov 21, 2017 at 08:46:59PM +, Alex Bennée wrote:
>
> Eric Sunshine writes:
> > Aside from those observations, it looks like the tokenizer in this
> > function is broken. For any input with the address enclosed in " > ">", the comment is lost entirely;

Eric Sunshine writes:
> The more I think about this, the less I consider this a bug in
> git-send-email. As noted, people might legitimately use a complex
> command (--cc-cmd="myscript--option arg"), so changing git-send-email
> to treat cc-cmd as an atomic string seems

On Mon, Nov 20, 2017 at 5:44 AM, Alex Bennée wrote:
> Eric Sunshine writes:
>> It is not at all clear, based upon this text, what this is fixing.
>> When you re-roll, please provide a description of the regression in
>> sufficient detail for

On Thu, Nov 16, 2017 at 10:48 AM, Alex Bennée wrote:
> Getting rid of Mail::Address regressed behaviour with common
> get_maintainer scripts such as the Linux kernel. Fix the missed corner
> case and add a test for it.
It is not at all clear, based upon this text, what