# [PATCH/RFC] Fix the result of "git grep -l -C <num>"

6 messages from 2012-01-23 to 2012-01-29. Participants: Albert Yale, Thomas Rast, Junio C Hamano.
Thread: https://gitlist.dev/t/29431

## Albert Yale, 2012-01-23 16:01

Subject: [PATCH/RFC] Fix the result of "git grep -l -C <num>"
Message-ID: <1327334484-35196-1-git-send-email-surfingalbert@gmail.com>
URL: https://gitlist.dev/e/1327334484-35196-1-git-send-email-surfingalbert%40gmail.com

```
When combining "git grep -l" with "-C <num>",
the first result is omitted.

Signed-off-by: Albert Yale <surfingalbert@gmail.com>
---
For example, if the following command should output a list of 3
different files (a.txt, b.txt, c.txt):

$ git grep -l -C 1 albert_yale
b.txt
c.txt

The first result (a.txt) will be missing.

Understandably, you wouldn't normally use "-C" with "-l",
but the output should still be correct.

My solution is to take "opt.name_only" into account before setting
"skip_first_line" in grep.c.

I've reproduced this bug with git version 1.7.8.3
and git version 1.7.9.rc2, both under Mac OS X 10.7.2.

Albert Yale

 builtin/grep.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/builtin/grep.c b/builtin/grep.c
index 9ce064a..076de21 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -1036,7 +1036,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 	if (use_threads) {
 		if (opt.pre_context || opt.post_context || opt.file_break ||
 		    opt.funcbody)
-			skip_first_line = 1;
+		{
+			if( ! opt.name_only )
+				skip_first_line = 1;
+		}
 		start_threads(&opt);
 	}
 #endif
-- 
1.7.8.3

```

## Thomas Rast, 2012-01-23 16:08

Subject: Re: [PATCH/RFC] Fix the result of "git grep -l -C <num>"
Message-ID: <8762g2ieq0.fsf@thomas.inf.ethz.ch>
URL: https://gitlist.dev/e/8762g2ieq0.fsf%40thomas.inf.ethz.ch
In-Reply-To: <1327334484-35196-1-git-send-email-surfingalbert@gmail.com>

```
Albert Yale <surfingalbert@gmail.com> writes:

> When combining "git grep -l" with "-C <num>",
> the first result is omitted.
[...]
> For example, if the following command should output a list of 3
> different files (a.txt, b.txt, c.txt):
>
> $ git grep -l -C 1 albert_yale
> b.txt
> c.txt

Nice catch.  Can you add a test?

Is -l the only option affected?  Why isn't, for example, -L?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

```

## Albert Yale, 2012-01-23 17:10

Subject: Re: [PATCH/RFC] Fix the result of "git grep -l -C <num>"
Message-ID: <CALEc4zGV6Oo-WR0vPE6=oEmm=fo4dd=nyBWFuK1oU7rmF9K41A@mail.gmail.com>
URL: https://gitlist.dev/e/CALEc4zGV6Oo-WR0vPE6%3DoEmm%3Dfo4dd%3DnyBWFuK1oU7rmF9K41A%40mail.gmail.com
In-Reply-To: <8762g2ieq0.fsf@thomas.inf.ethz.ch>

```
You're right. This solution is incomplete. It needs to take into
account "opt.unmatch_name_only", and possibly other states. I'm open
for suggestions.

I've just posted Version 2 of this patch.

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.

Albert

On Mon, Jan 23, 2012 at 11:08 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> Albert Yale <surfingalbert@gmail.com> writes:
>
>> When combining "git grep -l" with "-C <num>",
>> the first result is omitted.
> [...]
>> For example, if the following command should output a list of 3
>> different files (a.txt, b.txt, c.txt):
>>
>> $ git grep -l -C 1 albert_yale
>> b.txt
>> c.txt
>
> Nice catch.  Can you add a test?
>
> Is -l the only option affected?  Why isn't, for example, -L?
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch

```

## Thomas Rast, 2012-01-23 17:52

Subject: [PATCH] grep: fix -l/-L interaction with decoration lines
Message-ID: <74777e0e8633d980fee9a1a680a63535be042fdc.1327340917.git.trast@student.ethz.ch>
URL: https://gitlist.dev/e/74777e0e8633d980fee9a1a680a63535be042fdc.1327340917.git.trast%40student.ethz.ch
In-Reply-To: <CALEc4zGV6Oo-WR0vPE6=oEmm=fo4dd=nyBWFuK1oU7rmF9K41A@mail.gmail.com>

```
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

```

## Albert Yale, 2012-01-23 18:28

Subject: Re: [PATCH] grep: fix -l/-L interaction with decoration lines
Message-ID: <CALEc4zH3+gW412xtPE2qPnHjDzrOzL=8sn9vb31tjQoKJf7wZQ@mail.gmail.com>
URL: https://gitlist.dev/e/CALEc4zH3%2BgW412xtPE2qPnHjDzrOzL%3D8sn9vb31tjQoKJf7wZQ%40mail.gmail.com
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
>

```

## Junio C Hamano, 2012-01-29 23:49

Subject: Re: [PATCH] grep: fix -l/-L interaction with decoration lines
Message-ID: <7vhazedq87.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7vhazedq87.fsf%40alter.siamese.dyndns.org
In-Reply-To: <74777e0e8633d980fee9a1a680a63535be042fdc.1327340917.git.trast@student.ethz.ch>

```
Thanks, makes sense.

```