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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html