git-grep: option parsing conflicts with prefix-dash searches

Greetings.

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:

(2)	$ git grep -- '->cnt' net/ipv4/netfilter/
	fatal: bad flag '->cnt' used after filename

*bzzt*. This does not match typical behavior. Let alone that "--" is not a filename.

What works is (3).

(3)	$ git grep -- -- '->cnt' net/ipv4/netfilter/

But it almost looks like Morse code. Or Perl. Imagine I were to approxmiately search for all options in iptables's in-code help texts:

	git grep -- -- -- .

I think that overloading "--" was a bad choice. The option parser has many more awkward behavior, such as not allowing to bundle most options (`git log -z -p` vs. `git log -zp`) yet forcing it on other options (`git log -Spattern` vs `git log -S pattern`). The use of historic counts (cf. `git log -30` and `tail -30`) compared to a more modern `tail -n30`) also prohibits using many standard parsers (most notably getopt(3)), as they would recognize that as -3 -0.

As I said, it's a mess. And I know not whether any code can convince the "but we need to watch compatibility"-sayers, because this would definitely be a flag change.