git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Albert Yale <surfingalbert@gmail.com>
To: Thomas Rast <trast@student.ethz.ch>
Cc: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>, git@vger.kernel.org
Subject: Re: [PATCH] grep: fix -l/-L interaction with decoration lines
Date: Mon, 23 Jan 2012 13:28:32 -0500	[thread overview]
Message-ID: <CALEc4zH3+gW412xtPE2qPnHjDzrOzL=8sn9vb31tjQoKJf7wZQ@mail.gmail.com> (raw)
In-Reply-To: <74777e0e8633d980fee9a1a680a63535be042fdc.1327340917.git.trast@student.ethz.ch>

Your patch is clearly better than mine. I'll let you take over this bug.

Thanks for taking a deeper look into this,

Albert Yale

On Mon, Jan 23, 2012 at 12:52 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> From: Albert Yale <surfingalbert@gmail.com>
>
> In threaded mode, git-grep emits file breaks (enabled with context, -W
> and --break) into the accumulation buffers even if they are not
> required.  The output collection thread then uses skip_first_line to
> skip the first such line in the output, which would otherwise be at
> the very top.
>
> This is wrong when the user also specified -l/-L/-c, in which case
> every line is relevant.  While arguably giving these options together
> doesn't make any sense, git-grep has always quietly accepted it.  So
> do not skip anything in these cases.
>
> Signed-off-by: Albert Yale <surfingalbert@gmail.com>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
>> Reviewed-by: Thomas Rast <trast@student.ethz.ch>
>
> Please don't.  I didn't actually read the patch or look at the code,
> or say so, and you're claiming I did.  I was working purely from the
> commit message.
>
>> As for creating a test, I'm unfamiliar with the testing procedure for
>> git-core. A "how to" in the "Documentation" folder would be very
>> useful in that regard.
>
> Well, there's t/README.
>
>
> Here's a patch that also does -c and has tests.  Placing them was more
> finicky than I hoped; the list of files in the repo varies wildly
> across the test set.  It also exploits knowledge that git-ls-files
> order is the same as 'git grep -l' order, which might not be
> appropriate.
>
>
>  builtin/grep.c  |    6 ++++--
>  t/t7810-grep.sh |   22 ++++++++++++++++++++++
>  2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 9ce064a..1120b9f 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -1034,8 +1034,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
>
>  #ifndef NO_PTHREADS
>        if (use_threads) {
> -               if (opt.pre_context || opt.post_context || opt.file_break ||
> -                   opt.funcbody)
> +               if (!(opt.name_only || opt.unmatch_name_only ||
> +                     opt.count)
> +                   && (opt.pre_context || opt.post_context ||
> +                       opt.file_break || opt.funcbody))
>                        skip_first_line = 1;
>                start_threads(&opt);
>        }
> diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
> index 7ba5b16..75f4716 100755
> --- a/t/t7810-grep.sh
> +++ b/t/t7810-grep.sh
> @@ -246,6 +246,28 @@ do
>  done
>
>  cat >expected <<EOF
> +file
> +EOF
> +test_expect_success 'grep -l -C' '
> +       git grep -l -C1 foo >actual &&
> +       test_cmp expected actual
> +'
> +
> +cat >expected <<EOF
> +file:5
> +EOF
> +test_expect_success 'grep -l -C' '
> +       git grep -c -C1 foo >actual &&
> +       test_cmp expected actual
> +'
> +
> +test_expect_success 'grep -L -C' '
> +       git ls-files >expected &&
> +       git grep -L -C1 nonexistent_string >actual &&
> +       test_cmp expected actual
> +'
> +
> +cat >expected <<EOF
>  file:foo mmap bar_mmap
>  EOF
>
> --
> 1.7.9.rc2.215.gd9e83
>

  reply	other threads:[~2012-01-23 18:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-23 16:01 [PATCH/RFC] Fix the result of "git grep -l -C <num>" Albert Yale
2012-01-23 16:08 ` Thomas Rast
2012-01-23 17:10   ` Albert Yale
2012-01-23 17:52     ` [PATCH] grep: fix -l/-L interaction with decoration lines Thomas Rast
2012-01-23 18:28       ` Albert Yale [this message]
2012-01-29 23:49       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALEc4zH3+gW412xtPE2qPnHjDzrOzL=8sn9vb31tjQoKJf7wZQ@mail.gmail.com' \
    --to=surfingalbert@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=rene.scharfe@lsrfire.ath.cx \
    --cc=trast@student.ethz.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).