{"thread":{"id":"46469","subject":"[PATCH/RFC] setup: update error message to be more meaningful","startedAt":"2017-07-25T17:57:15Z","lastAt":"2017-10-04T14:18:54Z","messageCount":15,"participants":["Kaartic Sivaraam","Jonathan Nieder","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"325047","messageId":"0102015d7ae53b0a-a6505296-9257-4b0d-84d6-2152e17eb070-000000@eu-west-1.amazonses.com","threadId":"46469","inReplyTo":null,"subject":"[PATCH/RFC] setup: update error message to be more meaningful","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-25T17:57:09Z","receivedAt":"2017-07-25T17:57:15Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The error message shown when a flag is found when expecting a\nfilename wasn't clear as it didn't communicate what was wrong\nusing the 'suitable' words in *all* cases.\n\nCorrect case,\n\n        $ git rev-parse commit.c --flags\n        commit.c\n        --flags\n        fatal: bad flag '--flags' used after filename\n\nIncorrect case,\n\n        $ git grep \"test\" -n\n        fatal: bad flag '-n' used after filename\n\nChange the error message to be general and communicative. This results\nin the following output,\n\n        $ git rev-parse commit.c --flags\n        commit.c\n        --flags\n        fatal: found flag '--flags' in place of a filename\n\n        $ git grep \"test\" -n\n        fatal: found flag '-n' in place of a filename\n\nSigned-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>\n---\n setup.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/setup.c b/setup.c\nindex 860507e1fdb2d..0433d7889e6b3 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -230,7 +230,7 @@ void verify_filename(const char *prefix,\n \t\t     int diagnose_misspelt_rev)\n {\n \tif (*arg == '-')\n-\t\tdie(\"bad flag '%s' used after filename\", arg);\n+\t\tdie(\"found flag '%s' in place of a filename\", arg);\n \tif (looks_like_pathspec(arg) || check_filename(prefix, arg))\n \t\treturn;\n \tdie_verify_filename(prefix, arg, diagnose_misspelt_rev);\n\n--\nhttps://github.com/git/git/pull/388\n"},{"id":"325048","messageId":"1501006581.11979.2.camel@gmail.com","threadId":"46469","inReplyTo":"0102015d7ae53b0a-a6505296-9257-4b0d-84d6-2152e17eb070-000000@eu-west-1.amazonses.com","subject":"Re: [PATCH/RFC] setup: update error message to be more meaningful","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-25T18:16:21Z","receivedAt":"2017-07-25T18:16:00Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"I've added RFC to this patch's subject as I'm not sure if the new\nmessage is suitable. Suggestions for messages that are more suitable\nare welcome.\n\nIt seems that the function \"verify_filename\" is invoked by plumbing\ncommands like 'rev-parse', let me know if I've missed something about\nthem.\n\nI further noted that it's used by 'reset' but I wasn't able to \nmake 'reset' to invoke \"verify_filename\". In what case does 'reset'\ninvoke the concerned function ?\n\n-- \nKaartic\n"},{"id":"325076","messageId":"20170725212110.GG13924@aiede.mtv.corp.google.com","threadId":"46469","inReplyTo":"0102015d7ae53b0a-a6505296-9257-4b0d-84d6-2152e17eb070-000000@eu-west-1.amazonses.com","subject":"Re: [PATCH/RFC] setup: update error message to be more meaningful","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-07-25T21:21:10Z","receivedAt":"2017-07-25T21:21:19Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nKaartic Sivaraam wrote:\n\n> The error message shown when a flag is found when expecting a\n> filename wasn't clear as it didn't communicate what was wrong\n> using the 'suitable' words in *all* cases.\n>\n> Correct case,\n>\n>         $ git rev-parse commit.c --flags\n>         commit.c\n>         --flags\n>         fatal: bad flag '--flags' used after filename\n>\n> Incorrect case,\n>\n>         $ git grep \"test\" -n\n>         fatal: bad flag '-n' used after filename\n>\n> Change the error message to be general and communicative.\n\nThanks for writing this.  These examples describe *what* the behavior\nis but don't describe *why* it is wrong or what is expected in its\nplace.\n\nFor an initial guess: in the example\n\n\tgit grep test -n\n\nit is confusing that it says \"bad flag used after filename\" because\ntest isn't even a filename!  At first glance, I would imagine that any\nof the following behaviors would be nicer:\n\n 1. Treat the command as \"git grep -e test -n\", or in other words\n    \"do what I mean\" since it is clear enough, at least to humans.\n\n 2. Focus on \"argument\" instead of \"filename\" so that the message\n    could still apply: something like\n\n\tfatal: option '-n' must come before non-option arguments\n\n[...]\n> --- a/setup.c\n> +++ b/setup.c\n> @@ -230,7 +230,7 @@ void verify_filename(const char *prefix,\n>  \t\t     int diagnose_misspelt_rev)\n>  {\n>  \tif (*arg == '-')\n> -\t\tdie(\"bad flag '%s' used after filename\", arg);\n> +\t\tdie(\"found flag '%s' in place of a filename\", arg);\n\nProbably because of the background I am missing described above, it's\nnot clear to me that the new message is any better (or worse) than the\nexisting one.  The old message with \"after filename\" has the virtue of\nexplaining why an option is not expected there.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"325122","messageId":"1501074537.1792.2.camel@gmail.com","threadId":"46469","inReplyTo":"20170725212110.GG13924@aiede.mtv.corp.google.com","subject":"Re: [PATCH/RFC] setup: update error message to be more meaningful","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-26T13:08:57Z","receivedAt":"2017-07-26T13:08:39Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"Hello Jonathan Nieder,\n\nThanks for the reply!\n\nJonathan Nieder wrote:\n> \n> > The error message shown when a flag is found when expecting a\n> > filename wasn't clear as it didn't communicate what was wrong\n> > using the 'suitable' words in *all* cases.\n> > \n> > Correct case,\n> > \n> >         $ git rev-parse commit.c --flags\n> >         commit.c\n> >         --flags\n> >         fatal: bad flag '--flags' used after filename\n> > \n> > Incorrect case,\n> > \n> >         $ git grep \"test\" -n\n> >         fatal: bad flag '-n' used after filename\n> > \n> > Change the error message to be general and communicative.\n> \n> Thanks for writing this.  These examples describe *what* the behavior\n> is but don't describe *why* it is wrong or what is expected in its\n> place.\n> \nI've fixed that. The new commit message is found at the end of this\nmessage.\n\n> For an initial guess: in the example\n> \n> \tgit grep test -n\n> \n> it is confusing that it says \"bad flag used after filename\" because\n> test isn't even a filename!  At first glance, I would imagine that any\n> of the following behaviors would be nicer:\n> \n>  1. Treat the command as \"git grep -e test -n\", or in other words\n>     \"do what I mean\" since it is clear enough, at least to humans.\n> \nSorry, I actually didn't that. Could you rephrase it a little.\n\n>  2. Focus on \"argument\" instead of \"filename\" so that the message\n>     could still apply: something like\n> \n> \tfatal: option '-n' must come before non-option arguments\n> \nI used \"filename\" as the function indeed check if the argument given to\nit is a filename. How about,\n\n    fatal: expecting filename; found '-n'\n\n???\n\nIn the context it looks as follows,\n\n    $ git grep \"some random regex\" -n\n    fatal: expected filename; found '-n' \n\n    $ git rev-parse --flags\n    README.md\n    --flags\n    fatal: expected filename,\n    found '--flags'\n\n\n> Probably because of the background I am missing described above, it's\n> not clear to me that the new message is any better (or worse) than the\n> existing one.  The old message with \"after filename\" has the virtue of\n> explaining why an option is not expected there.\n> \nThat's surprising, I thought the phrase \"in place of filename\" was more\nexplanatory as it doesn't make assumptions about the previous arguments\nand specifies what was expected.\n\n> Thanks and hope that helps,\nYep\n\n\nThe modified commit message is found below. If it still seems to be\nmissing the *why*, let me know.\n\n    setup: update error message to be more meaningful\n    \n    The error message shown when a flag is found when expecting a\n    filename wasn't clear as it didn't communicate what was wrong\n    using the 'suitable' words in *all* cases.\n    \n            $ git ls-files\n            README.md\n            test-file\n    \n    Correct case,\n    \n            $ git rev-parse README.md --flags\n            README.md\n            --flags\n            fatal: bad flag '--flags' used after filename\n    \n    Incorrect case,\n    \n            $ git grep \"some random regex\" -n\n            fatal: bad flag '-n' used after filename\n    \n    The above case is incorrect as \"some random regex\" isn't a filename\n    in this case.\n    \n    Change the error message to be general and communicative. This results\n    in the following output,\n    \n            $ git rev-parse README.md --flags\n            README.md\n            --flags\n            fatal: found flag '--flags' in place of a filename\n    \n            $ git grep \"some random regex\" -n\n            fatal: found flag '-n' in place of a filename\n\n    -- \n    Kaartic\n"},{"id":"325147","messageId":"xmqqlgnbq7sc.fsf@gitster.mtv.corp.google.com","threadId":"46469","inReplyTo":"20170725212110.GG13924@aiede.mtv.corp.google.com","subject":"Re: [PATCH/RFC] setup: update error message to be more meaningful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-26T20:09:55Z","receivedAt":"2017-07-26T20:10:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> For an initial guess: in the example\n>\n> \tgit grep test -n\n>\n> ...\n>  2. Focus on \"argument\" instead of \"filename\" so that the message\n>     could still apply: something like\n>\n> \tfatal: option '-n' must come before non-option arguments\n\nI think this one is the most sensible.  There may or may not be a\nfile called \"test\" in the working tree, and the user may or may not\nmeant to look for a pattern \"test\".  What is wrong in the sample\ncommand line is that \"test\" is not a dashed option and yet it has a\ndashed option \"-n\" after it, and your version clearly explains it.\n"},{"id":"325237","messageId":"1501296270.2112.2.camel@gmail.com","threadId":"46469","inReplyTo":"xmqqlgnbq7sc.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH/RFC] setup: update error message to be more meaningful","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-29T02:44:30Z","receivedAt":"2017-07-29T02:44:06Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Wed, 2017-07-26 at 13:09 -0700, Junio C Hamano wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n> \n> > For an initial guess: in the example\n> > \n> > \tgit grep test -n\n> > \n> > ...\n> >  2. Focus on \"argument\" instead of \"filename\" so that the message\n> >     could still apply: something like\n> > \n> > \tfatal: option '-n' must come before non-option arguments\n> \n> I think this one is the most sensible.  There may or may not be a\n> file called \"test\" in the working tree, and the user may or may not\n> meant to look for a pattern \"test\".  What is wrong in the sample\n> command line is that \"test\" is not a dashed option and yet it has a\n> dashed option \"-n\" after it, and your version clearly explains it.\nThough the message seems to be most fitting one, I'm a little reluctant\nto use it as it \"might\" create a wrong picture on the minds of the user\nmaking them think this would be the case in other cases too, which we\nknow is not true. For example,\n\n\n    git log -p --full-diff master --stat\n\n    git commit -v Makefile --amend\n\n\nThe above are valid commands and produce expected result even though\nthe 'option argument' comes after the 'non-option' argument. Thus, I\nthought a \"general statement\" like the one above might create a wrong\npicture on the minds of user. Any thoughts about how to overcome this?\n\n-- \nKaartic\n"},{"id":"325239","messageId":"xmqqefszlx0e.fsf@gitster.mtv.corp.google.com","threadId":"46469","inReplyTo":"1501296270.2112.2.camel@gmail.com","subject":"Re: [PATCH/RFC] setup: update error message to be more meaningful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-29T03:53:05Z","receivedAt":"2017-07-29T03:53:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:\n\n> Though the message seems to be most fitting one, I'm a little reluctant\n> to use it as it \"might\" create a wrong picture on the minds of the user\n> making them think this would be the case in other cases too, which we\n> know is not true. For example,\n>\n>\n>     git log -p --full-diff master --stat\n>\n>     git commit -v Makefile --amend\n\nThese are accepted not by design but by accident.  \n\nI do not think we even document that you are allowed to do these in\n\"log\" and \"commit\" manual pages, and we should discourage them (I do\nnot even mind eventually removing these with the usual deprecation\ndance, but I do not think it is worth the noise).\n\n"},{"id":"325242","messageId":"1501330390.2001.1.camel@gmail.com","threadId":"46469","inReplyTo":"xmqqefszlx0e.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH/RFC] setup: update error message to be more meaningful","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-29T12:13:10Z","receivedAt":"2017-07-29T12:12:45Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Fri, 2017-07-28 at 20:53 -0700, Junio C Hamano wrote:\n> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:\n> \n> > Though the message seems to be most fitting one, I'm a little reluctant\n> > to use it as it \"might\" create a wrong picture on the minds of the user\n> > making them think this would be the case in other cases too, which we\n> > know is not true. For example,\n> > \n> > \n> >     git log -p --full-diff master --stat\n> > \n> >     git commit -v Makefile --amend\n> \n> These are accepted not by design but by accident.  \n> \n> I do not think we even document that you are allowed to do these in\n> \"log\" and \"commit\" manual pages, and we should discourage them (I do\n> not even mind eventually removing these with the usual deprecation\n> dance, but I do not think it is worth the noise).\n> \nThat's interesting. In that case, I'll go with the suggested statement,\nhappily!\n\n-- \nKaartic\n"},{"id":"325243","messageId":"0102015d8e5dd2c8-be70b5d5-8a65-4366-8cac-84a0f31ba744-000000@eu-west-1.amazonses.com","threadId":"46469","inReplyTo":"1501330390.2001.1.camel@gmail.com","subject":"[PATCH] setup: update error message to be more meaningful","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-29T12:41:39Z","receivedAt":"2017-07-29T12:41:46Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"The error message shown when a flag is found when expecting a\nfilename wasn't clear as it didn't communicate what was wrong\nusing the 'suitable' words in *all* cases.\n\n        $ git ls-files\n        README.md\n        test-file\n\nCorrect case,\n\n        $ git rev-parse README.md --flags\n        README.md\n        --flags\n        fatal: bad flag '--flags' used after filename\n\nIncorrect case,\n\n        $ git grep \"some random regex\" -n\n        fatal: bad flag '-n' used after filename\n\nThe above case is incorrect as \"some random regex\" isn't a filename\nin this case.\n\nChange the error message to be general and communicative. This results\nin the following output,\n\n        $ git rev-parse README.md --flags\n        README.md\n        --flags\n        fatal: option '--flags' must come before non-option arguments\n\n        $ git grep \"some random regex\" -n\n        fatal: option '-n' must come before non-option arguments\n\nSigned-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>\n---\n setup.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/setup.c b/setup.c\nindex 860507e1fdb2d..09c79328247dd 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -230,7 +230,7 @@ void verify_filename(const char *prefix,\n \t\t     int diagnose_misspelt_rev)\n {\n \tif (*arg == '-')\n-\t\tdie(\"bad flag '%s' used after filename\", arg);\n+\t\tdie(\"option '%s' must come before non-option arguments\", arg);\n \tif (looks_like_pathspec(arg) || check_filename(prefix, arg))\n \t\treturn;\n \tdie_verify_filename(prefix, arg, diagnose_misspelt_rev);\n\n--\nhttps://github.com/git/git/pull/393\n"},{"id":"325247","messageId":"xmqqy3r7jkbb.fsf@gitster.mtv.corp.google.com","threadId":"46469","inReplyTo":"1501330390.2001.1.camel@gmail.com","subject":"Re: [PATCH/RFC] setup: update error message to be more meaningful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-07-29T16:10:16Z","receivedAt":"2017-07-29T16:10:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:\n\n> On Fri, 2017-07-28 at 20:53 -0700, Junio C Hamano wrote:\n>> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:\n>> \n>> > Though the message seems to be most fitting one, I'm a little reluctant\n>> > to use it as it \"might\" create a wrong picture on the minds of the user\n>> > making them think this would be the case in other cases too, which we\n>> > know is not true. For example,\n>> > \n>> > \n>> >     git log -p --full-diff master --stat\n>> > \n>> >     git commit -v Makefile --amend\n>> \n>> These are accepted not by design but by accident.  \n>> \n>> I do not think we even document that you are allowed to do these in\n>> \"log\" and \"commit\" manual pages, and we should discourage them (I do\n>> not even mind eventually removing these with the usual deprecation\n>> dance, but I do not think it is worth the noise).\n>> \n> That's interesting. In that case, I'll go with the suggested statement,\n> happily!\n\nIt is not interesting at all.  It actually is disturbing that you\nhad the notion that these are \"valid\" command lines.\n\nWe perhaps need to somehow make sure new users won't be led to the\nmisunderstanding.  Improving our documentation is a good first step.\nWe might want to have a group of volunteers who actively monitor the\ninternets (e.g. stackoverflow and other places like that) and\ncorrect people who spread the same misunderstanding when they do.\n\n\n"},{"id":"325267","messageId":"1501411669.10533.2.camel@gmail.com","threadId":"46469","inReplyTo":"xmqqy3r7jkbb.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH/RFC] setup: update error message to be more meaningful","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-30T10:47:49Z","receivedAt":"2017-07-30T10:47:25Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Sat, 2017-07-29 at 09:10 -0700, Junio C Hamano wrote:\n> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:\n> > \n> > That's interesting. In that case, I'll go with the suggested statement,\n> > happily!\n> \n> It is not interesting at all.  It actually is disturbing that you\n> had the notion that these are \"valid\" command lines.\n> \nSeems I've used a sloppy statement, sorry about that. I actually\nthought these were valid because they \"worked\", no other reason.\n\n> We perhaps need to somehow make sure new users won't be led to the\n> misunderstanding.  Improving our documentation is a good first step.\nThat's something I could help with.\n\n-- \nKaartic\n"},{"id":"325268","messageId":"1501412630.10533.5.camel@gmail.com","threadId":"46469","inReplyTo":"1501411669.10533.2.camel@gmail.com","subject":"Re: [PATCH/RFC] setup: update error message to be more meaningful","fromName":"Kaartic Sivaraam","fromEmail":"kaarticsivaraam91196@gmail.com","sentAt":"2017-07-30T11:03:50Z","receivedAt":"2017-07-30T11:03:27Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Sun, 2017-07-30 at 16:17 +0530, Kaartic Sivaraam wrote:\n> On Sat, 2017-07-29 at 09:10 -0700, Junio C Hamano wrote:\n> > We perhaps need to somehow make sure new users won't be led to the\n> > misunderstanding.  Improving our documentation is a good first step.\n> \n> That's something I could help with.\n> \nI seem to be stuck a little with this. I'm not sure which other sub-\ncommands other than log and commit have similar behaviour as I'm aware\nof \"why\" they behave that way. I tried a little but thought it was\nbetter ask this one.\n\nWhat could be the source of this issue? (I guess this may help identify\nthe possible commands if the source is common.)\n\nWhich documentation(s) could be candidates for the suggested change?\nHow about \"Documentation/git.txt\"?\n\n-- \nKaartic\n"},{"id":"329469","messageId":"20171002173002.4278-1-kaarticsivaraam@gmail.com","threadId":"46469","inReplyTo":"xmqqlgnbq7sc.fsf@gitster.mtv.corp.google.com","subject":"[PATCH v2] setup: update error message to be more meaningful","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-10-02T17:30:02Z","receivedAt":"2017-10-02T17:30:25Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"From: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>\n\nThe error message shown when a flag is found when expecting a\nfilename wasn't clear as it didn't communicate what was wrong\nusing the 'suitable' words in *all* cases.\n\n        $ git ls-files\n        README.md\n        test-file\n\nCorrect case,\n\n        $ git rev-parse README.md --flags\n        README.md\n        --flags\n        fatal: bad flag '--flags' used after filename\n\nIncorrect case,\n\n        $ git grep \"some random regex\" -n\n        fatal: bad flag '-n' used after filename\n\nThe above case is incorrect as \"some random regex\" isn't a filename\nin this case.\n\nChange the error message to be general and communicative. This results\nin the following output,\n\n        $ git rev-parse README.md --flags\n        README.md\n        --flags\n        fatal: option '--flags' must come before non-option arguments\n\n        $ git grep \"some random regex\" -n\n        fatal: option '-n' must come before non-option arguments\n\nSigned-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>\n---\n Changes in v2:\n\n    Change in error message.\n\n setup.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/setup.c b/setup.c\nindex 860507e1f..09c793282 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -230,7 +230,7 @@ void verify_filename(const char *prefix,\n \t\t     int diagnose_misspelt_rev)\n {\n \tif (*arg == '-')\n-\t\tdie(\"bad flag '%s' used after filename\", arg);\n+\t\tdie(\"option '%s' must come before non-option arguments\", arg);\n \tif (looks_like_pathspec(arg) || check_filename(prefix, arg))\n \t\treturn;\n \tdie_verify_filename(prefix, arg, diagnose_misspelt_rev);\n-- \n2.14.1.935.ge2b2bcd8a\n\n"},{"id":"329504","messageId":"xmqq7ewdm5pm.fsf@gitster.mtv.corp.google.com","threadId":"46469","inReplyTo":"20171002173002.4278-1-kaarticsivaraam@gmail.com","subject":"Re: [PATCH v2] setup: update error message to be more meaningful","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-10-03T00:32:21Z","receivedAt":"2017-10-03T00:32:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:\n\n> Incorrect case,\n>\n>         $ git grep \"some random regex\" -n\n>         fatal: bad flag '-n' used after filename\n>\n> The above case is incorrect as \"some random regex\" isn't a filename\n> in this case.\n\nThe command line rule is to have dashed options first and then other\narguments, so I agree that \"option '-n' used after non-option\nargument(s)\" would be a better alternative.\n\n\"grep\" is an oddball, as it allows you to be lazy and omit the \"-e\"\noption when there is only one pattern, making a perfectly reasonable\n\"grep -e regex -n\" into an invalid \"grep regex -n\".\n\nAs an aside, I wonder if we want to _() the message.  It's outside\nthe scope of this fix, obviously.\n\n>  setup.c | 2 +-\n>  1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/setup.c b/setup.c\n> index 860507e1f..09c793282 100644\n> --- a/setup.c\n> +++ b/setup.c\n> @@ -230,7 +230,7 @@ void verify_filename(const char *prefix,\n>  \t\t     int diagnose_misspelt_rev)\n>  {\n>  \tif (*arg == '-')\n> -\t\tdie(\"bad flag '%s' used after filename\", arg);\n> +\t\tdie(\"option '%s' must come before non-option arguments\", arg);\n>  \tif (looks_like_pathspec(arg) || check_filename(prefix, arg))\n>  \t\treturn;\n>  \tdie_verify_filename(prefix, arg, diagnose_misspelt_rev);\n"},{"id":"329688","messageId":"1507126687.4204.6.camel@gmail.com","threadId":"46469","inReplyTo":"xmqq7ewdm5pm.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2] setup: update error message to be more meaningful","fromName":"Kaartic Sivaraam","fromEmail":"kaartic.sivaraam@gmail.com","sentAt":"2017-10-04T14:18:07Z","receivedAt":"2017-10-04T14:18:54Z","isPatch":true,"sender":{"key":"kaartic.sivaraam@gmail.com","avatar":"https://avatars.githubusercontent.com/u/12448084?v=4"},"body":"On Tue, 2017-10-03 at 09:32 +0900, Junio C Hamano wrote:\n> \n> As an aside, I wonder if we want to _() the message.  It's outside\n> the scope of this fix, obviously.\n> \n\nI'm surprised it isn't already! I think it should.\n\n\nAs an aside, I wanted to know whether we should add\n'test_expect_failure's for commands of the following sort,\n\n    git log -p --full-diff master --stat\n     \n    git commit -v Makefile --amend\n\njust to keep us reminded that these are accepted not by design but by\naccident ?\n\n---\nKaartic\n"}]}