{"thread":{"id":"57871","subject":"[PATCH] grep: add --max-count command line option","startedAt":"2022-05-12T13:20:17Z","lastAt":"2022-05-17T05:54:08Z","messageCount":8,"participants":["Carlos L. via GitGitGadget","Martin Ågren","Junio C Hamano","Paul Eggert","Carlos L."],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"455195","messageId":"pull.1264.git.git.1652361610103.gitgitgadget@gmail.com","threadId":"57871","inReplyTo":null,"subject":"[PATCH] grep: add --max-count command line option","fromName":"Carlos L. via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2022-05-12T13:20:09Z","receivedAt":"2022-05-12T13:20:17Z","isPatch":true,"sender":{"key":"00xc@protonmail.com","avatar":"https://avatars.githubusercontent.com/u/48725664?v=4"},"body":"From: =?UTF-8?q?Carlos=20L=C3=B3pez?= <00xc@protonmail.com>\n\nThis patch adds a command line option analogous to that of GNU\ngrep(1)'s -m / --max-count, which users might already be used to.\nThis makes it possible to limit the amount of matches shown in the\noutput while keeping the functionality of other options such as -C\n(show code context) or -p (show containing function), which would be\ndifficult to do with a shell pipeline (e.g. head(1)).\n\nSigned-off-by: Carlos López <00xc@protonmail.com>\n---\n grep: add --max-count command line option\n \n This patch adds a command line option analogous to that of GNU grep(1)'s\n -m / --max-count, which users might already be used to. This makes it\n possible to limit the amount of matches shown in the output while\n keeping the functionality of other options such as -C (show code\n context) or -p (show containing function), which would be difficult to\n do with a shell pipeline (e.g. head(1)).\n \n Signed-off-by: Carlos López 00xc@protonmail.com\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1264%2F00xc%2Fmaster-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1264/00xc/master-v1\nPull-Request: https://github.com/git/git/pull/1264\n\n Documentation/git-grep.txt | 7 +++++++\n builtin/grep.c | 2 ++\n grep.c | 2 ++\n grep.h | 1 +\n 4 files changed, 12 insertions(+)\n\ndiff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt\nindex 3d393fbac1b..02b36046475 100644\n--- a/Documentation/git-grep.txt\n+++ b/Documentation/git-grep.txt\n@@ -23,6 +23,7 @@ SYNOPSIS\n \t [--break] [--heading] [-p | --show-function]\n \t [-A ] [-B ] [-C ]\n \t [-W | --function-context]\n+\t [-m | --max-count ]\n \t [--threads ]\n \t [-f ] [-e] \n \t [--and|--or|--not|(|)|-e ...]\n@@ -238,6 +239,12 @@ providing this option will cause it to die.\n \t`git diff` works out patch hunk headers (see 'Defining a\n \tcustom hunk-header' in linkgit:gitattributes[5]).\n \n+-m ::\n+--max-count ::\n+\tLimit the amount of matches per file. When using the -v or\n+\t--invert-match option, the search stops after the specified\n+\tnumber of non-matches. Setting this option to 0 has no effect.\n+\n --threads ::\n \tNumber of grep worker threads to use.\n \tSee `grep.threads` in 'CONFIGURATION' for more information.\ndiff --git a/builtin/grep.c b/builtin/grep.c\nindex bcb07ea7f75..ba1894d5675 100644\n--- a/builtin/grep.c\n+++ b/builtin/grep.c\n@@ -961,6 +961,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)\n \t\tOPT_BOOL_F(0, \"ext-grep\", &external_grep_allowed__ignored,\n \t\t\t N_(\"allow calling of grep(1) (ignored by this build)\"),\n \t\t\t PARSE_OPT_NOCOMPLETE),\n+\t\tOPT_INTEGER('m', \"max-count\", &opt.max_count,\n+\t\t\tN_(\"maximum number of results per file (default: 0, no limit)\")),\n \t\tOPT_END()\n \t};\n \tgrep_prefix = prefix;\ndiff --git a/grep.c b/grep.c\nindex 82eb7da1022..173b6c27b6e 100644\n--- a/grep.c\n+++ b/grep.c\n@@ -1686,6 +1686,8 @@ static int grep_source_1(struct grep_opt *opt, struct grep_source *gs, int colle\n \t\tbol = eol + 1;\n \t\tif (!left)\n \t\t\tbreak;\n+\t\tif (opt->max_count && count == opt->max_count)\n+\t\t\tbreak;\n \t\tleft--;\n \t\tlno++;\n \t}\ndiff --git a/grep.h b/grep.h\nindex c722d25ed9d..25836f34314 100644\n--- a/grep.h\n+++ b/grep.h\n@@ -171,6 +171,7 @@ struct grep_opt {\n \tint show_hunk_mark;\n \tint file_break;\n \tint heading;\n+\tunsigned max_count;\n \tvoid *priv;\n \n \tvoid (*output)(struct grep_opt *opt, const void *data, size_t size);\n\nbase-commit: 277cf0bc36094f6dc4297d8c9cef79df045b735d\n-- \ngitgitgadget\n"},{"id":"455292","messageId":"CAN0heSoCiNnrknyfE7RrsLKcGcGqDYo9k9ubzcEo1r+CxO1hVQ@mail.gmail.com","threadId":"57871","inReplyTo":"pull.1264.git.git.1652361610103.gitgitgadget@gmail.com","subject":"Re: [PATCH] grep: add --max-count command line option","fromName":"Martin Ågren","fromEmail":"martin.agren@gmail.com","sentAt":"2022-05-14T18:16:05Z","receivedAt":"2022-05-14T18:16:25Z","isPatch":true,"sender":{"key":"martin.agren@gmail.com","avatar":null},"body":"Hi Carlos,\n\nWelcome to the mailing list. :-)\n\nOn Thu, 12 May 2022 at 21:13, Carlos L. via GitGitGadget\n wrote:\n>\n> From: =?UTF-8?q?Carlos=20L=C3=B3pez?= <00xc@protonmail.com>\n>\n> This patch adds a command line option analogous to that of GNU\n> grep(1)'s -m / --max-count, which users might already be used to.\n> This makes it possible to limit the amount of matches shown in the\n> output while keeping the functionality of other options such as -C\n> (show code context) or -p (show containing function), which would be\n> difficult to do with a shell pipeline (e.g. head(1)).\n\nMakes sense to me.\n\n> diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt\n> index 3d393fbac1b..02b36046475 100644\n> --- a/Documentation/git-grep.txt\n> +++ b/Documentation/git-grep.txt\n> @@ -23,6 +23,7 @@ SYNOPSIS\n> [--break] [--heading] [-p | --show-function]\n> [-A ] [-B ] [-C ]\n> [-W | --function-context]\n> + [-m | --max-count ]\n\nI think this should be\n\n [(-m | --max-count) ]\n\nsince the short form \"-m\" also wants to take \"\".\n\n> +-m ::\n> +--max-count ::\n> + Limit the amount of matches per file. When using the -v or\n> + --invert-match option, the search stops after the specified\n> + number of non-matches. Setting this option to 0 has no effect.\n\nPlease use `backticks` with `-v` and `--invert-match` so that they are\nset in monospace.\n\nRegarding the special value 0, it's a bit unclear what \"has no effect\"\nmeans. In particular, it can have an effect in the sense that when it\nis used like\n\n git grep -m 1 -m 0 foo\n\nit undoes the `-m 1`.\n\nBut also, that's not how my grep(1) behaves: with `-m 0`, it limits the\nnumber of matches to zero. I don't know how useful that is (can that\nzero-case be optimized by exiting with 1 before even trying to find the\nneedle!?), or if maybe different variants of grep handle this\ndifferently? If all grep implementations handle 0 by actually only\nemitting zero hits, I think it would be wise for us to handle 0 the same\nway.\n\nAs for overriding an earlier `-m `, which could be useful, it seems\nto me like `--no-max-count` would make sense.\n\nAll in all, I would suggest the following documentation:\n\n -m ::\n --max-count ::\n Limit the amount of matches per file. When using the `-v` or\n `--invert-match` option, the search stops after the specified\n number of non-matches. Use `--no-max-count` to countermand an\n earlier `--max-count` option on the command line.\n\n... and of course the matching implementation. :-) Maybe you could\nachieve that by using -1 to signal that there's no max-count in play?\nHow does that sound to you?\n\nEven if we want to handle the zero just like you do, I think this patch\nneeds a few tests. We should make sure to test the 0-case (whatever we\nend up wanting it to behave like), and probably the \"suppress an earlier\n-m by giving --no-max-count\" case. It also seems wise to set up some\ntest scenario where there are several files involved so that we can see\nthat we don't just print the first m matches *globally*, but that the\ncounter is really handled *per file*.\n\nI think this `-m` flag would be a nice addition. I know that I've been\nmissing something like it a few times. As you wrote in your commit\nmessage, `| head -3` can work for some use-cases, but definitely not for\nothers. This `-m` is a lot more granular than `-l` which can be seen as\na crude `-m 1`. Thanks for posting this patch! I hope you find my\ncomments useful.\n\nMartin\n"},{"id":"455306","messageId":"xmqqilq658b3.fsf@gitster.g","threadId":"57871","inReplyTo":"pull.1264.git.git.1652361610103.gitgitgadget@gmail.com","subject":"Re: [PATCH] grep: add --max-count command line option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-16T05:57:04Z","receivedAt":"2022-05-16T05:57:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Carlos L. via GitGitGadget\" writes:\n\n> From: =?UTF-8?q?Carlos=20L=C3=B3pez?= <00xc@protonmail.com>\n\nOfftopic, but I wonder why this line is encoded like so? The\n\"Signed-off-by:\" line is not, and it is safely transmitted, so\nit feels like we do not need to encode the in-body header that\nis added only for e-mail but not in the original commit...\n\n> This patch adds a command line option analogous to that of GNU\n> grep(1)'s -m / --max-count, which users might already be used to.\n> This makes it possible to limit the amount of matches shown in the\n> output while keeping the functionality of other options such as -C\n> (show code context) or -p (show containing function), which would be\n> difficult to do with a shell pipeline (e.g. head(1)).\n>\n> Signed-off-by: Carlos López <00xc@protonmail.com>\n> ---\n> ...\n> +-m ::\n> +--max-count ::\n> +\tLimit the amount of matches per file. When using the -v or\n> +\t--invert-match option, the search stops after the specified\n> +\tnumber of non-matches. Setting this option to 0 has no effect.\n> +\n\nGood thing that this is defined as \"per-file\" limit. If it were a\nglobal limit, the interaction between this one and \"--threads=\"\nwould have been interesting. Perhaps add a test to make sure the\nfeature continues to work with \"--threads=2\" (I am assuming that you\nhave already tested this implementation works with the option).\n\nMartin already commented on the wording \"no effect\"; I agree it is a\npoor choice of words from the point of view of \"overriding with 0\".\n\nIt indeed is curious why GNU grep chose to immediately exit with 1\nwhen \"-m 0\" was given, but that was decision made more than 20 years\nago (http://gnu.ist.utl.pt/software/grep/changes.html and look for\n\"2000-03-17\"). Between \"being consistent even with a seemingly\nuseless design choice made by somebody else\" and \"choose to be\ndifferent in a corner case where nobody should care and allow us to\nbe more useful\", I am slightly in favor in this particular case.\n\nWhat \"git grep -m -1\" should do? IIRC, OPT_INTEGER is for signed\ninteger but the new .max_count member, as well as the existing\n\"count\" that is compared with it, are of \"unsigned\" type. Either\nerroring out or treating it as unlimited is probably fine, but\nwhatever we do, we should document and have a test for it.\n\nThanks.\n\n\n\n"},{"id":"455309","messageId":"e89577f8-8f52-bf09-15f3-c534bf1a6c64@cs.ucla.edu","threadId":"57871","inReplyTo":"xmqqilq658b3.fsf@gitster.g","subject":"Re: [PATCH] grep: add --max-count command line option","fromName":"Paul Eggert","fromEmail":"eggert@cs.ucla.edu","sentAt":"2022-05-16T07:28:16Z","receivedAt":"2022-05-16T07:33:57Z","isPatch":true,"sender":{"key":"eggert@cs.ucla.edu","avatar":"https://avatars.githubusercontent.com/u/572024?v=4"},"body":"On 5/15/22 22:57, Junio C Hamano wrote:\n\n> It indeed is curious why GNU grep chose to immediately exit with 1\n> when \"-m 0\" was given,\n\nAs I vaguely recall, if \"-m 1\" stops before \"-m 2\" does, then the idea \nwas that it's reasonable for \"-m 0\" to stop before \"-m 1\" does, and the \nlogical place to stop is right at the start, before any matches are \nfound (i.e., exit with status 1).\n\nWhat would be more useful for 'grep -m 0' to do? (Sorry, I came into \nthis conversation just now.) Perhaps GNU 'grep -m 0' should change, if \nthere's something better for it to do.\n\n\n> What \"git grep -m -1\" should do? IIRC, OPT_INTEGER is for signed\n> integer but the new .max_count member, as well as the existing\n> \"count\" that is compared with it, are of \"unsigned\" type. Either\n> erroring out or treating it as unlimited is probably fine, but\n> whatever we do, we should document and have a test for it.\n\n'grep -m -1' treats the count as being unlimited, but this isn't \ndocumented and (from the code) appears to be accidental. It'd make sense \nfor it to be documented.\n"},{"id":"455312","messageId":"MHNbacVw7D6ZU3OJvgIqqRMu70HlgYIYQPduUEUnzWCqkGUsUGRLopGGWj-CbyjNilDcUfLB6elfSRgDOaob9cPpjeAf-I6xuMArQZ0y3io=@protonmail.com","threadId":"57871","inReplyTo":"e89577f8-8f52-bf09-15f3-c534bf1a6c64@cs.ucla.edu","subject":"Re: [PATCH] grep: add --max-count command line option","fromName":"Carlos L.","fromEmail":"00xc@protonmail.com","sentAt":"2022-05-16T08:38:05Z","receivedAt":"2022-05-16T08:38:26Z","isPatch":true,"sender":{"key":"00xc@protonmail.com","avatar":"https://avatars.githubusercontent.com/u/48725664?v=4"},"body":"Hi list,\n\nThanks to everyone who provided feedback :)\n\nOn Saturday, May 14th, 2022 at 20:16, Martin Ågren wrote:\n> I think this should be\n>\n> [(-m | --max-count) ]\n\n> Please use `backticks` with `-v` and `--invert-match` so that they are\n> set in monospace.\n\nI will add these suggestions to my patch.\n\n> Regarding the special value 0, it's a bit unclear what \"has no effect\"\n> means. In particular, it can have an effect in the sense that when it\n> is used like\n>\n> git grep -m 1 -m 0 foo\n>\n> it undoes the `-m 1`.\n>\n> But also, that's not how my grep(1) behaves: with `-m 0`, it limits the\n> number of matches to zero. I don't know how useful that is (can that\n> zero-case be optimized by exiting with 1 before even trying to find the\n> needle!?), or if maybe different variants of grep handle this\n> differently? If all grep implementations handle 0 by actually only\n> emitting zero hits, I think it would be wise for us to handle 0 the same\n> way.\n\nI agree the wording is not clear. I did not see a good use case for GNU's `-m 0`, which is why I used that value as unlimited. I am not sold on using `--no-max-count` or -1 *just* for consistency, but if someone can point to a good use case of GNU's `-m 0` (especially in git grep), I will gladly concede.\n\n> Even if we want to handle the zero just like you do, I think this patch\n> needs a few tests. We should make sure to test the 0-case (whatever we\n> end up wanting it to behave like), and probably the \"suppress an earlier\n> -m by giving --no-max-count\" case. It also seems wise to set up some\n> test scenario where there are several files involved so that we can see\n> that we don't just print the first m matches globally, but that the\n> counter is really handled per file.\n\nThis seems sound. Is there any documentation on how to write tests for git?\n\nOn Monday, May 16th, 2022 at 07:57, Junio C Hamano wrote:\n> Good thing that this is defined as \"per-file\" limit. If it were a\n> global limit, the interaction between this one and \"--threads=\"\n> would have been interesting. Perhaps add a test to make sure the\n> feature continues to work with \"--threads=2\" (I am assuming that you\n> have already tested this implementation works with the option).\n\nI did and I found no unexpected behavior.\n\n> What \"git grep -m -1\" should do? IIRC, OPT_INTEGER is for signed\n> integer but the new .max_count member, as well as the existing\n> \"count\" that is compared with it, are of \"unsigned\" type. Either\n> erroring out or treating it as unlimited is probably fine, but\n> whatever we do, we should document and have a test for it.\n\nI would favor treating it as an error. As mentioned above, using 0 to describe \"unlimited matches\" (e.g. the default) is my preference, but I am willing to concede if someone can think of a good use for `-m 0`. Also, from the implementation side (although not as important) it looks better: if we allow negative values, we need to distinguish between -1 (unlimited) and -4 (display error to user, probably) - the patch is much simpler right now. And just as a side note, we avoid an issue in the pretty much insignificant use case of giving a very big value (UINT_MAX) for `-m` and it overflowing into -1, thus not properly limiting the number of matches.\n\nOn Monday, May 16th, 2022 at 09:28, Paul Eggert wrote:\n> As I vaguely recall, if \"-m 1\" stops before \"-m 2\" does, then the idea\n> was that it's reasonable for \"-m 0\" to stop before \"-m 1\" does, and the\n> logical place to stop is right at the start, before any matches are\n> found (i.e., exit with status 1).\n\nAs I mentioned above, I do not see what this `-m 0` behavior is useful for, but if someone could show me an use for it I would appreciate it.\n\nAgain, thank you everyone for your comments.\n"},{"id":"455321","messageId":"xmqqee0t5wv5.fsf@gitster.g","threadId":"57871","inReplyTo":"e89577f8-8f52-bf09-15f3-c534bf1a6c64@cs.ucla.edu","subject":"Re: [PATCH] grep: add --max-count command line option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-16T15:18:54Z","receivedAt":"2022-05-16T15:19:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Eggert writes:\n\n> On 5/15/22 22:57, Junio C Hamano wrote:\n>\n>> It indeed is curious why GNU grep chose to immediately exit with 1\n>> when \"-m 0\" was given,\n>\n> As I vaguely recall, if \"-m 1\" stops before \"-m 2\" does, then the idea\n> was that it's reasonable for \"-m 0\" to stop before \"-m 1\" does, and\n> the logical place to stop is right at the start, before any matches\n> are found (i.e., exit with status 1).\n>\n> What would be more useful for 'grep -m 0' to do? (Sorry, I came into\n> this conversation just now.) Perhaps GNU 'grep -m 0' should change, if \n> there's something better for it to do.\n\n\"grep -m 0\" that declares a failure upfront because it is asked to\nstop before finding any match, combined with the fact that the\ncommand is expected to signal a failure after finding no matches, is\nan optimization that is mathmatically correct ;-)\n\nIt was asked as a part of discussion on a proposed patch to teach\nthe same \"-m \" option to \"git grep\" what it\nought to mean to give \"-m 0\". As we are too accustomed to the \"last\ncommand line option wins\" behaviour, I initially did not find the\nbehaviour of the proposed patch, where 0 (or negative) stood for\n\"unlimited\", quite natural and useful (e.g. it allows overriding a\nhardcoded default option in aliases, \"[alias] gg = grep -m 4\"), and\nthen was surprised by the \"'-m 0' is an immediate failure\" in GNU\ngrep. I would call it mathematically pure and correct but of\ndubious utility.\n\nSorry for not providing enough context. Full discussion is seen at \nhttps://lore.kernel.org/git/pull.1264.git.git.1652361610103.gitgitgadget@gmail.com/\n\n>> What \"git grep -m -1\" should do? IIRC, OPT_INTEGER is for signed\n>> integer but the new .max_count member, as well as the existing\n>> \"count\" that is compared with it, are of \"unsigned\" type. Either\n>> erroring out or treating it as unlimited is probably fine, but\n>> whatever we do, we should document and have a test for it.\n>\n> 'grep -m -1' treats the count as being unlimited, but this isn't\n> documented and (from the code) appears to be accidental. It'd make\n> sense for it to be documented.\n\nThanks. The question was asked for the proposed addition to \"git\ngrep\", but it is funny to see it apply equally well to GNU grep ;-).\n\n"},{"id":"455322","messageId":"xmqq1qwt5w2e.fsf@gitster.g","threadId":"57871","inReplyTo":"MHNbacVw7D6ZU3OJvgIqqRMu70HlgYIYQPduUEUnzWCqkGUsUGRLopGGWj-CbyjNilDcUfLB6elfSRgDOaob9cPpjeAf-I6xuMArQZ0y3io=@protonmail.com","subject":"Re: [PATCH] grep: add --max-count command line option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-16T15:36:09Z","receivedAt":"2022-05-16T15:36:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Carlos L.\" <00xc@protonmail.com> writes:\n\n>> Even if we want to handle the zero just like you do, I think this patch\n>> needs a few tests. We should make sure to test the 0-case (whatever we\n>> end up wanting it to behave like), and probably the \"suppress an earlier\n>> -m by giving --no-max-count\" case. It also seems wise to set up some\n>> test scenario where there are several files involved so that we can see\n>> that we don't just print the first m matches globally, but that the\n>> counter is really handled per file.\n>\n> This seems sound. Is there any documentation on how to write tests for git?\n\nt/README and Documentation/MyFirstContribution would be two good\nplaces to start.\n\n>> What \"git grep -m -1\" should do? IIRC, OPT_INTEGER is for signed\n>> integer but the new .max_count member, as well as the existing\n>> \"count\" that is compared with it, are of \"unsigned\" type. Either\n>> erroring out or treating it as unlimited is probably fine, but\n>> whatever we do, we should document and have a test for it.\n>\n> I would favor treating it as an error. As mentioned above, using 0\n> to describe \"unlimited matches\" (e.g. the default) is my\n> preference, but I am willing to concede if someone can think of a\n> good use for `-m 0`.\n\nWith Devil's advocate hat on.\n\n\"GNU grep has been doing so for the past 20 years and existing users\nof the command expects '-m 0' to behave that way\" is a good enough\nreason, especially if '-m 0' is not the only possible way to say\n\"unlimited\".\n\n> Also, from the implementation side (although\n> not as important) it looks better: if we allow negative values, we\n> need to distinguish between -1 (unlimited) and -4 (display error\n> to user, probably)\n\nIf we are going to document \"you can pass a negative value to\nexplicitly say 'unlimited', which is a useful way to countermand\nanother `-m ` that appear earlier on the command line\", then -1\nand -4 would equally be 'unlimited' and there is no need to\ndistinguish anything.\n\nDevil's advocate hat off.\n\nI personally do not mind if \"-m \" means \"unlimited\",\nas long as that is clearly documented and tested, but for long time\n\"GNU grep\" users \"-m 0\" might appear surprising (not necessarily\nbecause they would find that the \"-m 0\" that immediately fails is\nuseful, but because the behaviour is deliberately made different).\n\nThanks.\n\n"},{"id":"455373","messageId":"27c09033-a7f4-e9f4-5871-42ac38111b75@cs.ucla.edu","threadId":"57871","inReplyTo":"xmqq1qwt5w2e.fsf@gitster.g","subject":"Re: [PATCH] grep: add --max-count command line option","fromName":"Paul Eggert","fromEmail":"eggert@cs.ucla.edu","sentAt":"2022-05-17T05:53:59Z","receivedAt":"2022-05-17T05:54:08Z","isPatch":true,"sender":{"key":"eggert@cs.ucla.edu","avatar":"https://avatars.githubusercontent.com/u/572024?v=4"},"body":"On 5/16/22 08:36, Junio C Hamano wrote:\n> \"GNU grep has been doing so for the past 20 years and existing users\n> of the command expects '-m 0' to behave that way\" is a good enough\n> reason, especially if '-m 0' is not the only possible way to say\n> \"unlimited\".\n\nYes, I'm inclined in the same direction, now that I see more of the \ncontext. That is, GNU grep can continue what it's long been doing, with \nthe only change being to the documentation so that we document -m-1 as \nmeaning \"unlimited\". This minimizes possible disruption to existing \nscripts and satisfies the use case of having a way to turn off any \npreviously-appearing -m option.\n\nI installed the attached to the GNU grep master doc to do that. Hope \nthis works for you.\n\nFrom 2deca89cf0c7a99450f88cf0abfadd336511633f Mon Sep 17 00:00:00 2001\nFrom: Paul Eggert \nDate: Mon, 16 May 2022 12:18:26 -0700\nSubject: [PATCH] grep: document -m better\n\n* doc/grep.in.1, doc/grep.texi: Document behavior of -m 0 and -m -1.\nThis documents longstanding behavior, and is consistent with\nhow git grep -m will likely behave.\n---\n doc/grep.in.1 | 10 ++++++++++\n doc/grep.texi | 4 ++++\n 2 files changed, 14 insertions(+)\n\ndiff --git a/doc/grep.in.1 b/doc/grep.in.1\nindex aba085a..5ba90ee 100644\n--- a/doc/grep.in.1\n+++ b/doc/grep.in.1\n@@ -321,6 +321,16 @@ Scanning each input file stops upon first match.\n Stop reading a file after\n .I NUM\n matching lines.\n+If\n+.I NUM\n+is zero,\n+.B grep\n+stops right away without reading input.\n+A\n+.I NUM\n+of \\-1 is treated as infinity and\n+.B grep\n+does not stop; this is the default.\n If the input is standard input from a regular file,\n and\n .I NUM\ndiff --git a/doc/grep.texi b/doc/grep.texi\nindex b9688c8..b073fa7 100644\n--- a/doc/grep.texi\n+++ b/doc/grep.texi\n@@ -341,6 +341,10 @@ Scanning each input file stops upon first match.\n @opindex --max-count\n @cindex max-count\n Stop after the first @var{num} selected lines.\n+If @var{num} is zero, @command{grep} stops right away without reading input.\n+A @var{num} of @minus{}1 is treated as infinity and @command{grep}\n+does not stop; this is the default.\n+\n If the input is standard input from a regular file,\n and @var{num} selected lines are output,\n @command{grep} ensures that the standard input is positioned\n-- \n2.34.1\n\n"}]}