Jan Engelhardt [off-list ref] writes:
Just about now I wanted to grep for accesses of a particular struct
member. Needless to say that it was not a very amusing experience.
I would expect that (1) probably fails:
(1) $ git grep '->cnt' net/ipv4/netfilter/
error: unknown switch `>'
So far so good, seems reasonable and matches what I would expect from
most other userspace tools. So let's add -- to terminate the option
list:
Also you can say "grep -e '->cnt'". Not just "git grep" but regular grep
understands this, too.
(2) $ git grep -- '->cnt' net/ipv4/netfilter/
fatal: bad flag '->cnt' used after filename
*bzzt*.
This indeed is bzzt, especially if you had a file called "./->cnt" in the
work tree. That would mean that you cannot tell the command to look for a
pattern in the work tree.
But because you are not giving anything before "--", that "git grep" is
not looking for anything. Indeed, (2) is a user error. If you try this:
$ git grep a -- '->cnt' net/ipv4/netfilter/
does do what the command line specifies: Look for a pattern "a" in files
whose names match given pathspecs ('->cnt' or 'net/ipv4/netfilter/').
What works is (3).
(3) $ git grep -- -- '->cnt' net/ipv4/netfilter/
Huh? Now I am lost. Weren't you looking for a pattern "->cnt"?
And if this command looks for and finds the string '->cnt' in files whose
path match net/ipv4/netfilter/ pathspec, I would say it _is_ a bug.
The command line looks for "--" (the first one) as a pattern, and
interprets the second "--" as your attempt to tell git that '->cnt' is not
an option but is a pathspec. So it looks for a pattern "--" in files
whose names match given pathspecs( again '->cnt' or 'net/ipv4/netfilter/').
But it almost looks like Morse code.
Indeed. But did (3) really work? I tried it myself in a copy of the
kernel repository, and it found lines that contain '--' in files whose
names match net/ipv4/netfilter/ pathspec, as my copy of the kernel source
does not have a file '->cnt' at all.