Re: [PATCH v3 2/3] Remove now useless email-address parsing code

2018-01-08 Thread Alex Bennée
Matthieu Moy <g...@matthieu-moy.fr> writes: > We now use Mail::Address unconditionaly, hence parse_mailboxes is now > dead code. Remove it and its tests. > > Signed-off-by: Matthieu Moy <g...@matthieu-moy.fr> Reviewed-by: Alex Bennée <alex.ben...@linaro.org&g

Re: [PATCH v3 1/3] send-email: add and use a local copy of Mail::Address

2018-01-08 Thread Alex Bennée
l::Address as a hard dependency, > but it's easy enough to save the trouble of extra-dependency to the end > user or packager. > > Signed-off-by: Matthieu Moy <g...@matthieu-moy.fr> Reviewed-by: Alex Bennée <alex.ben...@linaro.org> > --- > No ch

Re: [PATCH] send-email: add test for Linux's get_maintainer.pl

2018-01-05 Thread Alex Bennée
Matthieu Moy <g...@matthieu-moy.fr> writes: > From: Alex Bennée <alex.ben...@linaro.org> > > We had a regression that broke Linux's get_maintainer.pl. Using > Mail::Address to parse email addresses fixed it, but let's protect > against future regressions. > >

Re: [RFC PATCH 2/2] Remove now useless email-address parsing code

2018-01-04 Thread Alex Bennée
example.com> Jane Doe]); > - > -my @known_failure_list = (q[Jane\ Doe <j...@example.com>], > - q["Doe, Ja"ne <j...@example.com>], > - q["Doe, Katarina" Jane <j...@example.com>], > - q[Jane j...@example.com], > - q["Jane "Kat"a" ri"na" ",Doe" <j...@example.com>], > - q[Jane Doe], > - q[Jane "Doe <j...@example.com>"], > - q[\"Jane Doe <j...@example.com>], > - q[Jane\"\" Doe <j...@example.com>], > - q['Jane "Katarina\" \' Doe' <j...@example.com>]); > - > -foreach my $str (@success_list) { > - my @expected = map { $_->format } Mail::Address->parse("$str"); > - my @actual = Git::parse_mailboxes("$str"); > - is_deeply(\@expected, \@actual, qq[same output : $str]); > -} > - > -TODO: { > - local $TODO = "known breakage"; > - foreach my $str (@known_failure_list) { > - my @expected = map { $_->format } Mail::Address->parse("$str"); > - my @actual = Git::parse_mailboxes("$str"); > - is_deeply(\@expected, \@actual, qq[same output : $str]); > - } > -} > - > -my $is_passing = eval { Test::More->is_passing }; > -exit($is_passing ? 0 : 1) unless $@ =~ /Can't locate object method/; -- Alex Bennée

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

2017-12-12 Thread Alex Bennée
e. I less bothered my the potentially shipping a git specific copy than ensuring the packagers pick up the dependency when they do their builds. Do we already have a mechanism for testing for non-core perl modules during the "configure" phase of git? -- Alex Bennée

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

2017-12-11 Thread Alex Bennée
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 ;-) I guess the full solution is to make Mail::Address a hard dependency? -- Alex Bennée

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

2017-11-22 Thread Alex Bennée
88 So that is about 88 perl modules used in the code base. How many of them are not part of the core perl distribution? Should the solution be to just make Mail::Address a hard dependency and not have the fallback? -- Alex Bennée

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

2017-11-21 Thread Alex Bennée
Eric Sunshine <sunsh...@sunshineco.com> writes: > A few more comments/observations... > > On Thu, Nov 16, 2017 at 10:48 AM, Alex Bennée <alex.ben...@linaro.org> wrote: >> diff --git a/perl/Git.pm b/perl/Git.pm >> @@ -93

[PATCH v2] git-send-email: fix --cc-cmd get_maintainer.pl regression

2017-11-20 Thread Alex Bennée
Signed-off-by: Alex Bennée <alex.ben...@linaro.org> Cc: Eric Sunshine <sunsh...@sunshineco.com> --- perl/Git.pm | 3 +++ t/t9000/test.pl | 3 ++- t/t9001-send-email.sh | 16 3 files changed, 21 insertions(+), 1 deletion(-) diff --git a/perl/Git.pm b/perl/

[PATCH] git-send-email: fix --cc-cmd get_maintainer.pl regression

2017-11-20 Thread Alex Bennée
Signed-off-by: Alex Bennée <alex.ben...@linaro.org> Cc: Eric Sunshine <sunsh...@sunshineco.com> --- perl/Git.pm | 3 +++ t/t9000/test.pl | 3 ++- t/t9001-send-email.sh | 16 3 files changed, 21 insertions(+), 1 deletion(-) diff --git a/perl/Git.pm b/perl/

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

2017-11-20 Thread Alex Bennée
Eric Sunshine <sunsh...@sunshineco.com> writes: > On Thu, Nov 16, 2017 at 10:48 AM, Alex Bennée <alex.ben...@linaro.org> wrote: >> Getting rid of Mail::Address regressed behaviour with common >> get_maintainer scripts such as the Linux kernel. Fix the missed co

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

2017-11-16 Thread Alex Bennée
Alex Bennée <alex.ben...@linaro.org> writes: > 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. > > diff --git a/t/t9001-send-email.sh b/t/t9001-send-email

[PATCH] git-send-email: fix get_maintainer.pl regression

2017-11-16 Thread Alex Bennée
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. Fixes: cc9075067776ebd34cc08f31bf78bb05f12fd879 Signed-off-by: Alex Bennée <alex.ben...@linaro.org> --- perl/Git.pm

Re: Poor performance of git describe in big repos

2013-06-03 Thread Alex Bennée
On 31 May 2013 10:57, Alex Bennée kernel-hac...@bennee.com wrote: On 31 May 2013 09:46, Thomas Rast tr...@inf.ethz.ch wrote: So that deleted all unannotated tags pointing at commits, and then it was fast. Curious. However, if that turns out to be the culprit, it's not fixable currently[1

Re: Poor performance of git describe in big repos

2013-06-03 Thread Alex Bennée
On 31 May 2013 17:17, Jeff King p...@peff.net wrote: On Fri, May 31, 2013 at 12:27:11PM +0200, Thomas Rast wrote: Thomas Rast tr...@inf.ethz.ch writes: However, if that turns out to be the culprit, it's not fixable currently[1]. Having commits with insanely long messages is just, well,

Re: Poor performance of git describe in big repos

2013-05-31 Thread Alex Bennée
On 30 May 2013 20:30, John Keeping j...@keeping.me.uk wrote: On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote: Alex Bennée kernel-hac...@bennee.com writes: On 30 May 2013 16:33, Thomas Rast tr...@inf.ethz.ch wrote: Alex Bennée kernel-hac...@bennee.com writes: snip

Re: Poor performance of git describe in big repos

2013-05-31 Thread Alex Bennée
On 31 May 2013 09:24, Thomas Rast tr...@inf.ethz.ch wrote: Alex Bennée kernel-hac...@bennee.com writes: On 30 May 2013 20:30, John Keeping j...@keeping.me.uk wrote: On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote: Alex Bennée kernel-hac...@bennee.com writes: On 30 May 2013 16:33

Re: Poor performance of git describe in big repos

2013-05-31 Thread Alex Bennée
On 31 May 2013 09:32, John Keeping j...@keeping.me.uk wrote: On Fri, May 31, 2013 at 09:14:49AM +0100, Alex Bennée wrote: On 30 May 2013 20:30, John Keeping j...@keeping.me.uk wrote: On Thu, May 30, 2013 at 06:21:55PM +0200, Thomas Rast wrote: Alex Bennée kernel-hac...@bennee.com writes

Re: Poor performance of git describe in big repos

2013-05-31 Thread Alex Bennée
On 31 May 2013 09:46, Thomas Rast tr...@inf.ethz.ch wrote: Alex Bennée kernel-hac...@bennee.com writes: I think you are right. I was brave (well I assumed the tags would come back from the upstream repo) and ran: git for-each-ref | grep refs/tags | grep commit | cut -d '/' -f 3 | xargs git

Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
Hi, I'm a fairly heavy user of the magit Emacs extension for interacting with my git repos. However I've noticed there are some cases where lag is very high. By analysing strace output of emacs calling git I found two commands that where particularly problematic when interrogating the repo:

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
2.03% git [kernel.kallsyms] [k] clear_page_c So I'm guessing it's spending a lot of non-cache efficient time un-packing and processing the deltas? -- Alex. On 30 May 2013 12:48, John Keeping j...@keeping.me.uk wrote: On Thu, May 30, 2013 at 11:38:32AM +0100, Alex Bennée wrote: One factor

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
] clear_page_c I'm not sure why libcrypto features so highly in the results -- Alex. On 30 May 2013 12:33, Ramkumar Ramachandra artag...@gmail.com wrote: Alex Bennée wrote: time /usr/bin/git --no-pager traversed 223 commits real0m4.817s user0m4.320s sys 0m0.464s I'm quite clueless

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
j...@keeping.me.uk wrote: On Thu, May 30, 2013 at 11:38:32AM +0100, Alex Bennée wrote: One factor might be the size of my repo (.git is around 2.4G). Could this just be due to computational cost of searching through large packs to walk the commit chain? Is there any way to make this easier

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
On 30 May 2013 14:45, Duy Nguyen pclo...@gmail.com wrote: On Thu, May 30, 2013 at 8:34 PM, Alex Bennée kernel-hac...@bennee.com wrote: snip Thanks. Can you share verify-pack -v output of pack-a9ba133a6f25ffa74c3c407e09ab030f8745b201.pack? I think you need to put it somewhere on Internet

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
On 30 May 2013 15:32, Ramkumar Ramachandra artag...@gmail.com wrote: Alex Bennée wrote: And through my special repo: 41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3 33.62% git libz.so.1.2.3.4 [.] inflate_fast 10.39% git libz.so.1.2.3.4 [.] adler32 2.03

Re: Poor performance of git describe in big repos

2013-05-30 Thread Alex Bennée
On 30 May 2013 16:33, Thomas Rast tr...@inf.ethz.ch wrote: Alex Bennée kernel-hac...@bennee.com writes: 41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3 33.62% git libz.so.1.2.3.4 [.] inflate_fast 10.39% git libz.so.1.2.3.4 [.] adler32 2.03% git