{"thread":{"id":"22539","subject":"git-grep: option parsing conflicts with prefix-dash searches","startedAt":"2010-02-05T23:09:11Z","lastAt":"2010-02-08T01:06:45Z","messageCount":12,"participants":["Jan Engelhardt","Santi Béjar","Junio C Hamano","Jeff King","Miles Bader"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133743","messageId":"alpine.LSU.2.01.1002052351060.30204@obet.zrqbmnf.qr","threadId":"22539","inReplyTo":null,"subject":"git-grep: option parsing conflicts with prefix-dash searches","fromName":"Jan Engelhardt","fromEmail":"jengelh@medozas.de","sentAt":"2010-02-05T23:09:11Z","receivedAt":"2010-02-05T23:09:11Z","isPatch":false,"sender":{"key":"jengelh@medozas.de","avatar":null},"body":"Greetings.\n\n\nJust about now I wanted to grep for accesses of a particular struct \nmember. Needless to say that it was not a very amusing experience.\nI would expect that (1) probably fails:\n\n(1)\t$ git grep '->cnt' net/ipv4/netfilter/\n\terror: unknown switch `>'\n\nSo far so good, seems reasonable and matches what I would expect from \nmost other userspace tools. So let's add -- to terminate the option \nlist:\n\n(2)\t$ git grep -- '->cnt' net/ipv4/netfilter/\n\tfatal: bad flag '->cnt' used after filename\n\n*bzzt*. This does not match typical behavior. Let alone that \"--\"\nis not a filename.\n\nWhat works is (3).\n\n(3)\t$ git grep -- -- '->cnt' net/ipv4/netfilter/\n\nBut it almost looks like Morse code. Or Perl. Imagine I were to\napproxmiately search for all options in iptables's in-code help texts:\n\n\tgit grep -- -- -- .\n\nI think that overloading \"--\" was a bad choice. The option parser has\nmany more awkward behavior, such as not allowing to bundle most\noptions (`git log -z -p` vs. `git log -zp`) yet forcing it on other\noptions (`git log -Spattern` vs `git log -S pattern`). The use of\nhistoric counts (cf. `git log -30` and `tail -30`) compared to a more\nmodern `tail -n30`) also prohibits using many standard parsers\n(most notably getopt(3)), as they would recognize that as -3 -0.\n\nAs I said, it's a mess. And I know not whether any code can convince\nthe \"but we need to watch compatibility\"-sayers, because this would\ndefinitely be a flag change.\n"},{"id":"133754","messageId":"alpine.LSU.2.01.1002060009430.30204@obet.zrqbmnf.qr","threadId":"22539","inReplyTo":"alpine.LSU.2.01.1002052351060.30204@obet.zrqbmnf.qr","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Jan Engelhardt","fromEmail":"jengelh@medozas.de","sentAt":"2010-02-05T23:17:49Z","receivedAt":"2010-02-05T23:17:49Z","isPatch":false,"sender":{"key":"jengelh@medozas.de","avatar":null},"body":"On Saturday 2010-02-06 00:09, Jan Engelhardt wrote:\n\n>What works is (3).\n>\n>(3)\t$ git grep -- -- '->cnt' net/ipv4/netfilter/\n\nNo, I spoke too soon. This command will search for --, not ->cnt.\nSo git cannot search for patterns starting with a dash at all,\nas I see it. This is getting fun..\n\n>As I said, it's a mess. And I know not whether any code can convince\n>the \"but we need to watch compatibility\"-sayers, because this would\n>definitely be a flag change.\n"},{"id":"133755","messageId":"adf1fd3d1002051527j72fd302byc85a2f0980ce9998@mail.gmail.com","threadId":"22539","inReplyTo":"alpine.LSU.2.01.1002060009430.30204@obet.zrqbmnf.qr","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2010-02-05T23:27:19Z","receivedAt":"2010-02-05T23:27:19Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Sat, Feb 6, 2010 at 12:17 AM, Jan Engelhardt wrote:\n> On Saturday 2010-02-06 00:09, Jan Engelhardt wrote:\n>\n>>What works is (3).\n>>\n>>(3)    $ git grep -- -- '->cnt' net/ipv4/netfilter/\n>\n> No, I spoke too soon. This command will search for --, not ->cnt.\n> So git cannot search for patterns starting with a dash at all,\n> as I see it. This is getting fun..\n\nYou should use -e:\n\n -e\n The next parameter is the pattern. This option has to be\nused for patterns starting with - and should be used in scripts\npassing user input to grep.\n\nThe working command is:\n\n$ git grep -e '->cnt' net/ipv4/netfilter/\n\nAlthough there is not such pattern in net/ipv4/netfilter, maybe you\nwanted '->counters' :-)\n\nHTH,\nSanti\n"},{"id":"133756","messageId":"7vsk9fs1j9.fsf@alter.siamese.dyndns.org","threadId":"22539","inReplyTo":"alpine.LSU.2.01.1002052351060.30204@obet.zrqbmnf.qr","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-05T23:31:06Z","receivedAt":"2010-02-05T23:31:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan Engelhardt writes:\n\n> Just about now I wanted to grep for accesses of a particular struct \n> member. Needless to say that it was not a very amusing experience.\n> I would expect that (1) probably fails:\n>\n> (1)\t$ git grep '->cnt' net/ipv4/netfilter/\n> \terror: unknown switch `>'\n>\n> So far so good, seems reasonable and matches what I would expect from \n> most other userspace tools. So let's add -- to terminate the option \n> list:\n\nAlso you can say \"grep -e '->cnt'\". Not just \"git grep\" but regular grep\nunderstands this, too.\n\n> (2)\t$ git grep -- '->cnt' net/ipv4/netfilter/\n> \tfatal: bad flag '->cnt' used after filename\n>\n> *bzzt*.\n\nThis indeed is bzzt, especially if you had a file called \"./->cnt\" in the\nwork tree. That would mean that you cannot tell the command to look for a\npattern in the work tree.\n\nBut because you are not giving anything before \"--\", that \"git grep\" is\nnot looking for anything. Indeed, (2) is a user error. If you try this:\n\n $ git grep a -- '->cnt' net/ipv4/netfilter/\n\ndoes do what the command line specifies: Look for a pattern \"a\" in files\nwhose names match given pathspecs ('->cnt' or 'net/ipv4/netfilter/').\n\n> What works is (3).\n>\n> (3)\t$ git grep -- -- '->cnt' net/ipv4/netfilter/\n\nHuh? Now I am lost. Weren't you looking for a pattern \"->cnt\"?\n\nAnd if this command looks for and finds the string '->cnt' in files whose\npath match net/ipv4/netfilter/ pathspec, I would say it _is_ a bug.\n\nThe command line looks for \"--\" (the first one) as a pattern, and\ninterprets the second \"--\" as your attempt to tell git that '->cnt' is not\nan option but is a pathspec. So it looks for a pattern \"--\" in files\nwhose names match given pathspecs( again '->cnt' or 'net/ipv4/netfilter/').\n\n> But it almost looks like Morse code.\n\nIndeed. But did (3) really work? I tried it myself in a copy of the\nkernel repository, and it found lines that contain '--' in files whose\nnames match net/ipv4/netfilter/ pathspec, as my copy of the kernel source\ndoes not have a file '->cnt' at all.\n"},{"id":"133757","messageId":"7v7hqrs1d0.fsf@alter.siamese.dyndns.org","threadId":"22539","inReplyTo":"alpine.LSU.2.01.1002060009430.30204@obet.zrqbmnf.qr","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-05T23:34:51Z","receivedAt":"2010-02-05T23:34:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan Engelhardt writes:\n\n> On Saturday 2010-02-06 00:09, Jan Engelhardt wrote:\n>\n>>What works is (3).\n>>\n>>(3)\t$ git grep -- -- '->cnt' net/ipv4/netfilter/\n>\n> No, I spoke too soon. This command will search for --, not ->cnt.\n> So git cannot search for patterns starting with a dash at all,\n> as I see it. This is getting fun..\n>\n>>As I said, it's a mess. And I know not whether any code can convince\n>>the \"but we need to watch compatibility\"-sayers, because this would\n>>definitely be a flag change.\n\nI guess our mails crossed. You don't have to worry about \"flag change\",\nas I don't think there is any change necessary.\n\nYou just need to learn:\n\n (1) \"-e\" can come before a string to tell git: \"this might look like\n an option to you but it isn't; it is what I am looking for\"; and\n\n (2) Everything that follows \"--\" are pathspecs, not revs nor options.\n\nAnd all is well.\n"},{"id":"133774","messageId":"20100206035143.GA31784@sigill.intra.peff.net","threadId":"22539","inReplyTo":"7vsk9fs1j9.fsf@alter.siamese.dyndns.org","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-02-06T03:51:43Z","receivedAt":"2010-02-06T03:51:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 05, 2010 at 03:31:06PM -0800, Junio C Hamano wrote:\n\n> Jan Engelhardt writes:\n> \n> > Just about now I wanted to grep for accesses of a particular struct \n> > member. Needless to say that it was not a very amusing experience.\n> > I would expect that (1) probably fails:\n> >\n> > (1)\t$ git grep '->cnt' net/ipv4/netfilter/\n> > \terror: unknown switch `>'\n> >\n> > So far so good, seems reasonable and matches what I would expect from \n> > most other userspace tools. So let's add -- to terminate the option \n> > list:\n> \n> Also you can say \"grep -e '->cnt'\". Not just \"git grep\" but regular grep\n> understands this, too.\n\nGNU grep understands \"grep -- '->cnt'\", so I find myself typing it a\nlot. Even though \"--\" is used for revision and pathname separation, I\ndon't think there is a conflict in also using it to separate options\nfrom patterns for the case that there is no \"-e\" at all. In other words:\n\n git grep -- foo\n\nis not ambiguous. That \"--\" could not possibly be separating revisions\nfrom pathnames because we have not yet seen any pattern, which is bogus.\nIn a case like:\n\n git grep -e pattern -- foo\n\nI think it is clear that the \"--\" is separating pathnames, because we\nalready have a pathname. This matches standard grep, which will treat\nthe first non-option as a pattern only if we have no \"-e\" pattern.\n\nSo I think we can do just do this:\n\ndiff --git a/builtin-grep.c b/builtin-grep.c\nindex 0ef849c..46ffc1d 100644\n--- a/builtin-grep.c\n+++ b/builtin-grep.c\n@@ -889,6 +889,16 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \t\t/* die the same way as if we did it at the beginning */\n \t\tsetup_git_directory();\n \n+\t/*\n+\t * skip a -- separator; we know it cannot be\n+\t * separating revisions from pathnames if\n+\t * we haven't even had any patterns yet\n+\t */\n+\tif (argc > 0 && !opt.pattern_list && !strcmp(argv[0], \"--\")) {\n+\t\targv++;\n+\t\targc--;\n+\t}\n+\n \t/* First unrecognized non-option token */\n \tif (argc > 0 && !opt.pattern_list) {\n \t\tappend_grep_pattern(&opt, argv[0], \"command line\", 0,\n\nand make everybody happy. But I admit I haven't thought about it more\nthan 5 minutes or so, so perhaps there is a case I am missing that will\nbe ambiguous or confusing. The worst I could come up with is the\ndouble-double-dash case:\n\n git grep -- pattern revision -- pathname\n\nIt is perhaps not as pretty as\n\n git grep -e pattern revision -- pathname\n\nbut I don't think it is ambiguous.\n\n> > (2)\t$ git grep -- '->cnt' net/ipv4/netfilter/\n> > \tfatal: bad flag '->cnt' used after filename\n> >\n> > *bzzt*.\n> \n> This indeed is bzzt, especially if you had a file called \"./->cnt\" in the\n> work tree. That would mean that you cannot tell the command to look for a\n> pattern in the work tree.\n> \n> But because you are not giving anything before \"--\", that \"git grep\" is\n> not looking for anything. Indeed, (2) is a user error. If you try this:\n\nThat is not quite true. The way \"git grep\" is implemented now, it is\nactually grepping for \"--\". parse_options stops at the \"--\", leaving it\nin argv, and then we assume whatever is left by parse_options is a\npattern (since we saw no \"-e\"). But of course it is looking in the\n'->cnt' pathspec (or revision!), which is bogus (and gets you \"bad flag used\nafter filename\").\n\nBut as you noted with:\n\n> > What works is (3).\n> >\n> > (3)\t$ git grep -- -- '->cnt' net/ipv4/netfilter/\n\n...disambiguating the pathspec with the extra \"--\" gets it past option\nparsing and looking for \"--\".\n\nSo actually my patch above is breaking somebody who truly wanted to grep\nfor \"--\" by doing\n\n git grep --\n\nbut that is sufficiently insane that I'm not too worried about it.\n\n-Peff\n"},{"id":"133778","messageId":"7v7hqrdkxb.fsf@alter.siamese.dyndns.org","threadId":"22539","inReplyTo":"20100206035143.GA31784@sigill.intra.peff.net","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-06T04:53:36Z","receivedAt":"2010-02-06T04:53:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The worst I could come up with is the\n> double-double-dash case:\n>\n> git grep -- pattern revision -- pathname\n>\n> It is perhaps not as pretty as\n>\n> git grep -e pattern revision -- pathname\n>\n> but I don't think it is ambiguous.\n\nI don't think if \"ambiguous or not\" is what we are after to begin with.\n\nI have known GNU extended grep implementations long enough but never saw\nthat \"--\" used to quote a pattern. Is it worth supporting to begin with?\n\n> So actually my patch above is breaking somebody who truly wanted to grep\n> for \"--\" by doing\n>\n> git grep --\n>\n> but that is sufficiently insane that I'm not too worried about it.\n\nI would say \"git grep -- pattern\" is sufficiently insane enough that\nI'm not worried about it at all. Interpreting \"git grep --\" as a request\nto look for double-dash feels million times saner than that, actually.\n\nUnless somebody comes up with example of that pattern's wide use. Point\nme to some well known open source software's source trees that use \"--\"\nfor such a purpose in one of its shell script or Makefile.\n"},{"id":"133782","messageId":"87mxzmsrqc.fsf@catnip.gol.com","threadId":"22539","inReplyTo":"7v7hqrdkxb.fsf@alter.siamese.dyndns.org","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2010-02-06T08:17:31Z","receivedAt":"2010-02-06T08:17:31Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano writes:\n> I have known GNU extended grep implementations long enough but never saw\n> that \"--\" used to quote a pattern. Is it worth supporting to begin with?\n\nWell, it is a natural consequence of the way command-line parsing works\nin typical GNU progs; \"--\" doesn't mean \"files follow\", it means \"no\nmore options\"....\n\n-Miles\n\n-- \nI'd rather be consing.\n"},{"id":"133793","messageId":"20100206115817.GA11605@sigill.intra.peff.net","threadId":"22539","inReplyTo":"7v7hqrdkxb.fsf@alter.siamese.dyndns.org","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-02-06T11:58:17Z","receivedAt":"2010-02-06T11:58:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 05, 2010 at 08:53:36PM -0800, Junio C Hamano wrote:\n\n> > git grep -- pattern revision -- pathname\n> [...]\n> I don't think if \"ambiguous or not\" is what we are after to begin with.\n> \n> I have known GNU extended grep implementations long enough but never saw\n> that \"--\" used to quote a pattern. Is it worth supporting to begin with?\n\nI think so. It was the first thing the original poster in this thread\ntried. It is also something I have tried (and still do, then grumblingly\nretype \"-e pattern\"). And it certainly makes sense from a user\nperspective; it is the same end-of-options signal that most other\nprograms take.\n\nSo I think it is a convenient interface improvement, nothing more. If it\nwere somehow onerous to support, I would say that no, it is not worth\nit. But it really is only a few lines of code, and I do not think the\nbehavior change is hurting any real-world cases (which is what I was\ntrying to show earlier).\n\nI suspect you are not familiar with it because you are enough of an\nold-timer to have worked with the many non-GNU greps that require \"-e\"\nto specify a funny pattern and so got used to that habit.\n\n> I would say \"git grep -- pattern\" is sufficiently insane enough that\n> I'm not worried about it at all. Interpreting \"git grep --\" as a request\n> to look for double-dash feels million times saner than that, actually.\n\nI don't think \"grep --\" is sane at all, since it is broken under GNU\ngrep. And because \"--\" is a special token in option parsing, I would\nexpect it to need \"git grep -e --\".\n\n> Unless somebody comes up with example of that pattern's wide use. Point\n> me to some well known open source software's source trees that use \"--\"\n> for such a purpose in one of its shell script or Makefile.\n\nOK. Try:\n\n http://www.google.com/codesearch?hl=en&sa=N&q=grep.*%5Cs--%5Cs++lang:shell&ct=rr&cs_r=lang:shell\n\nSome are false positives, but it looks like libtool's generated\nconfigure scripts use it (which is in literally hundreds of projects),\nopenssh's fixpaths script, ffmpeg's configure script, even a use in a\nplan9 script.\n\nAnd that's just the first page of results. So I think I am not the only\none.\n\n-Peff\n"},{"id":"133812","messageId":"7v8wb64623.fsf@alter.siamese.dyndns.org","threadId":"22539","inReplyTo":"20100206115817.GA11605@sigill.intra.peff.net","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-06T17:39:32Z","receivedAt":"2010-02-06T17:39:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Fri, Feb 05, 2010 at 08:53:36PM -0800, Junio C Hamano wrote:\n>\n>> > git grep -- pattern revision -- pathname\n>> [...]\n>> I don't think if \"ambiguous or not\" is what we are after to begin with.\n>> \n>> I have known GNU extended grep implementations long enough but never saw\n>> that \"--\" used to quote a pattern. Is it worth supporting to begin with?\n>\n> I think so. It was the first thing the original poster in this thread\n> tried. It is also something I have tried (and still do, then grumblingly\n> retype \"-e pattern\"). And it certainly makes sense from a user\n> perspective; it is the same end-of-options signal that most other\n> programs take.\n\nOk, then let's take that (perhaps before 1.7.0 perhaps after).\n"},{"id":"133851","messageId":"20100207044415.GA6622@coredump.intra.peff.net","threadId":"22539","inReplyTo":"7v8wb64623.fsf@alter.siamese.dyndns.org","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-02-07T04:44:15Z","receivedAt":"2010-02-07T04:44:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 06, 2010 at 09:39:32AM -0800, Junio C Hamano wrote:\n\n> > I think so. It was the first thing the original poster in this thread\n> > tried. It is also something I have tried (and still do, then grumblingly\n> > retype \"-e pattern\"). And it certainly makes sense from a user\n> > perspective; it is the same end-of-options signal that most other\n> > programs take.\n> \n> Ok, then let's take that (perhaps before 1.7.0 perhaps after).\n\nHere it is with a commit message and some tests. While it is a minor\nchange, we are pretty late in the release cycle, so perhaps it is best\nto leave it post-1.7.0 just to be on the safe side.\n\n-- >8 --\nSubject: [PATCH] accept \"git grep -- pattern\"\n\nCurrently the only way to \"quote\" a grep pattern that might\nbegin with a dash is to use \"git grep -e pattern\". This\nworks just fine, and is also the way right way to do it on\nmany traditional grep implemenations.\n\nSome people prefer to use \"git grep -- pattern\", however, as\n\"--\" is the usual \"end of options\" marker, and at least GNU\ngrep and Solaris 10 grep support this. This patch makes that\nsyntax work.\n\nThere is a slight behavior change, in that \"git grep -- $X\"\nused to be interpreted as \"grep for -- in $X\". However, that\nusage is questionable. \"--\" is usually the end-of-options\nmarker, so \"git grep\" was unlike many other greps in\ntreating it as a literal pattern (e.g., both GNU grep and\nSolaris 10 grep will treat \"grep --\" as missing a pattern).\n\nSigned-off-by: Jeff King \n---\n builtin-grep.c | 10 ++++++++++\n t/t7002-grep.sh | 33 +++++++++++++++++++++++++++++++++\n 2 files changed, 43 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-grep.c b/builtin-grep.c\nindex 26d4deb..63d4b95 100644\n--- a/builtin-grep.c\n+++ b/builtin-grep.c\n@@ -861,6 +861,16 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \t\t\t PARSE_OPT_STOP_AT_NON_OPTION |\n \t\t\t PARSE_OPT_NO_INTERNAL_HELP);\n \n+\t/*\n+\t * skip a -- separator; we know it cannot be\n+\t * separating revisions from pathnames if\n+\t * we haven't even had any patterns yet\n+\t */\n+\tif (argc > 0 && !opt.pattern_list && !strcmp(argv[0], \"--\")) {\n+\t\targv++;\n+\t\targc--;\n+\t}\n+\n \t/* First unrecognized non-option token */\n \tif (argc > 0 && !opt.pattern_list) {\n \t\tappend_grep_pattern(&opt, argv[0], \"command line\", 0,\ndiff --git a/t/t7002-grep.sh b/t/t7002-grep.sh\nindex 7144f81..0b583cb 100755\n--- a/t/t7002-grep.sh\n+++ b/t/t7002-grep.sh\n@@ -434,4 +434,37 @@ test_expect_success 'grep -Fi' '\n \ttest_cmp expected actual\n '\n \n+test_expect_success 'setup double-dash tests' '\n+cat >double-dash <\n+other\n+EOF\n+git add double-dash\n+'\n+\n+cat >expected <\n+EOF\n+test_expect_success 'grep -- pattern' '\n+\tgit grep -- \"->\" >actual &&\n+\ttest_cmp expected actual\n+'\n+test_expect_success 'grep -- pattern -- pathspec' '\n+\tgit grep -- \"->\" -- double-dash >actual &&\n+\ttest_cmp expected actual\n+'\n+test_expect_success 'grep -e pattern -- path' '\n+\tgit grep -e \"->\" -- double-dash >actual &&\n+\ttest_cmp expected actual\n+'\n+\n+cat >expected <actual &&\n+\ttest_cmp expected actual\n+'\n+\n test_done\n-- \n1.7.0.rc1.58.g769126\n"},{"id":"133903","messageId":"7vljf41qoq.fsf@alter.siamese.dyndns.org","threadId":"22539","inReplyTo":"20100207044415.GA6622@coredump.intra.peff.net","subject":"Re: git-grep: option parsing conflicts with prefix-dash searches","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-08T01:06:45Z","receivedAt":"2010-02-08T01:06:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Here it is with a commit message and some tests. While it is a minor\n> change, we are pretty late in the release cycle, so perhaps it is best\n> to leave it post-1.7.0 just to be on the safe side.\n\nYour explanation that \"-- marks the end of options\" makes perfect sense\nand it is not inconsistent with what we do either. \"grep\" is an oddball\nthat among its non-option arguments the first one _can_ be a non-path\n(namely, the single pattern you are looking for), but with your patch,\nthat logic is nicely expressed, too.\n\nI am tempted to push it into 1.7.0 but I'd keep it in 'next' for now.\n\nThanks.\n"}]}