* [PATCH/RFC] Fix the result of "git grep -l -C <num>"
@ 2012-01-23 16:01 Albert Yale
2012-01-23 16:08 ` Thomas Rast
0 siblings, 1 reply; 6+ messages in thread
From: Albert Yale @ 2012-01-23 16:01 UTC (permalink / raw)
To: git; +Cc: trast, rene.scharfe, Albert Yale
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH/RFC] Fix the result of "git grep -l -C <num>"
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
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Rast @ 2012-01-23 16:08 UTC (permalink / raw)
To: Albert Yale; +Cc: git, rene.scharfe
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH/RFC] Fix the result of "git grep -l -C <num>"
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
0 siblings, 1 reply; 6+ messages in thread
From: Albert Yale @ 2012-01-23 17:10 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, rene.scharfe
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] grep: fix -l/-L interaction with decoration lines
2012-01-23 17:10 ` Albert Yale
@ 2012-01-23 17:52 ` Thomas Rast
2012-01-23 18:28 ` Albert Yale
2012-01-29 23:49 ` Junio C Hamano
0 siblings, 2 replies; 6+ messages in thread
From: Thomas Rast @ 2012-01-23 17:52 UTC (permalink / raw)
To: Albert Yale; +Cc: René Scharfe, git
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] grep: fix -l/-L interaction with decoration lines
2012-01-23 17:52 ` [PATCH] grep: fix -l/-L interaction with decoration lines Thomas Rast
@ 2012-01-23 18:28 ` Albert Yale
2012-01-29 23:49 ` Junio C Hamano
1 sibling, 0 replies; 6+ messages in thread
From: Albert Yale @ 2012-01-23 18:28 UTC (permalink / raw)
To: Thomas Rast; +Cc: René Scharfe, git
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] grep: fix -l/-L interaction with decoration lines
2012-01-23 17:52 ` [PATCH] grep: fix -l/-L interaction with decoration lines Thomas Rast
2012-01-23 18:28 ` Albert Yale
@ 2012-01-29 23:49 ` Junio C Hamano
1 sibling, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2012-01-29 23:49 UTC (permalink / raw)
To: Thomas Rast; +Cc: Albert Yale, René Scharfe, git
Thanks, makes sense.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-29 23:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2012-01-29 23:49 ` Junio C Hamano
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).