{"thread":{"id":"55570","subject":"bug:git-check-ignore exit status is wrong for negative patterns when -v option used","startedAt":"2021-04-27T16:30:22Z","lastAt":"2021-05-03T03:09:41Z","messageCount":9,"participants":["Jeremy Faith","Bagas Sanjaya","Junio C Hamano","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"423115","messageId":"CY4P132MB00885C970ACF5A277F06E40385419@CY4P132MB0088.NAMP132.PROD.OUTLOOK.COM","threadId":"55570","inReplyTo":null,"subject":"bug:git-check-ignore exit status is wrong for negative patterns when -v option used","fromName":"Jeremy Faith","fromEmail":"jeremy.faith@jci.com","sentAt":"2021-04-27T16:30:13Z","receivedAt":"2021-04-27T16:30:22Z","isPatch":false,"sender":{"key":"jeremy.faith@jci.com","avatar":null},"body":"Hi,\n\ngit version 2.31.1.362.g311531c9de\ngit-check-ignore \nWhen a negative pattern is the last .gitignore match the -v option causes the exit status to be 0 rather than the expected 1.\ne.g say .gitignore contains one line: !hello\ngit check-ignore hello #outputs nothing\necho $? #shows correct exit status=1 i.e None of the provided paths are ignored.\nbut\ngit check-ignore -v hello #output is next line\n.gitignore:4:!hello\thello\necho $? #shows wrong exit status=0 i.e. One or more of the provided paths is ignored\n\nFollowing change seems to fix it for me\n--- a/builtin/check-ignore.c\n+++ b/builtin/check-ignore.c\n@@ -114,7 +114,7 @@ static int check_ignore(struct dir_struct *dir,\n                }\n                if (!quiet && (pattern || show_non_matching))\n                        output_pattern(pathspec.items[i].original, pattern);\n-               if (pattern)\n+               if (pattern && !(pattern->flags & PATTERN_FLAG_NEGATIVE))\n                        num_ignored++;\n        }\n        free(seen);\n\nRegards,\nJeremy Faith"},{"id":"423177","messageId":"3ea4e4c8-9723-4af6-5f07-9141c3001986@gmail.com","threadId":"55570","inReplyTo":"CY4P132MB00885C970ACF5A277F06E40385419@CY4P132MB0088.NAMP132.PROD.OUTLOOK.COM","subject":"Re: bug:git-check-ignore exit status is wrong for negative patterns when -v option used","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-04-28T06:15:32Z","receivedAt":"2021-04-28T06:15:39Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 27/04/21 23.30, Jeremy Faith wrote:\n> Hi,\n> \n> git version 2.31.1.362.g311531c9de\n> git-check-ignore\n> When a negative pattern is the last .gitignore match the -v option causes the exit status to be 0 rather than the expected 1.\n> e.g say .gitignore contains one line: !hello\n> git check-ignore hello #outputs nothing\n> echo $? #shows correct exit status=1 i.e None of the provided paths are ignored.\n> but\n> git check-ignore -v hello #output is next line\n> .gitignore:4:!hello\thello\n> echo $? #shows wrong exit status=0 i.e. One or more of the provided paths is ignored\n> \n> Following change seems to fix it for me\n> --- a/builtin/check-ignore.c\n> +++ b/builtin/check-ignore.c\n> @@ -114,7 +114,7 @@ static int check_ignore(struct dir_struct *dir,\n>                 }\n>                 if (!quiet && (pattern || show_non_matching))\n>                         output_pattern(pathspec.items[i].original, pattern);\n> -               if (pattern)\n> +               if (pattern && !(pattern->flags & PATTERN_FLAG_NEGATIVE))\n>                         num_ignored++;\n>         }\n>         free(seen);\n> \nI tried to apply this patch from the mbox, but it was corrupted, so I had to\nmanually write the changes above. I tested that with your reproduction case and\nit worked as expected.\n\nBut anyway, please send the proper patch and (preferentially) with the test\nconsisting of the reproduction case.\n\nThanks.\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"423179","messageId":"xmqqfszac25x.fsf@gitster.g","threadId":"55570","inReplyTo":"CY4P132MB00885C970ACF5A277F06E40385419@CY4P132MB0088.NAMP132.PROD.OUTLOOK.COM","subject":"Re: bug:git-check-ignore exit status is wrong for negative patterns when -v option used","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-28T07:13:14Z","receivedAt":"2021-04-28T07:13:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeremy Faith writes:\n\n> git version 2.31.1.362.g311531c9de\n> git-check-ignore \n> When a negative pattern is the last .gitignore match the -v option causes the exit status to be 0 rather than the expected 1.\n> e.g say .gitignore contains one line: !hello\n> git check-ignore hello #outputs nothing\n> echo $? #shows correct exit status=1 i.e None of the provided paths are ignored.\n> but\n> git check-ignore -v hello #output is next line\n> .gitignore:4:!hello\thello\n> echo $? #shows wrong exit status=0 i.e. One or more of the provided paths is ignored\n\nHmph. This is kind of understandable given the history of the\ncommand, which was *not* about programatically ask \"is this path\nignored?\" question at all. Instead, it was invented to answer this\nquestion: I am puzzled by the fact that Git considers this path is\nto be ignored (or \"not to be ignored\"). Show me which entry in what\nexclude file made the final decision to ignore (or \"not to ignore\")\nit to help me debug my ignore file(s).\n\nAnd the exit code was to signal \"yes, I found a relevant entry\",\nwhich made sense for the tool's nature as a debugging aid.\n\nSo, I suspect that this is working as designed/intended. I agree\nthat it is debatable that the way it was designed to work is a good\none, though.\n\n"},{"id":"423268","messageId":"CY4P132MB00885F00AAA46BCFAC76881B855F9@CY4P132MB0088.NAMP132.PROD.OUTLOOK.COM","threadId":"55570","inReplyTo":"xmqqfszac25x.fsf@gitster.g","subject":"Re: bug:git-check-ignore exit status is wrong for negative patterns when -v option used","fromName":"Jeremy Faith","fromEmail":"jeremy.faith@jci.com","sentAt":"2021-04-29T14:10:05Z","receivedAt":"2021-04-29T14:10:09Z","isPatch":false,"sender":{"key":"jeremy.faith@jci.com","avatar":null},"body":"Junio C Hamano wrote:\n \n>Jeremy Faith writes:\n\n>> git version 2.31.1.362.g311531c9de\n>> git-check-ignore \n>> When a negative pattern is the last .gitignore match the -v option causes the exit status to be 0 rather than the expected 1.\n>> e.g say .gitignore contains  one line: !hello\n>> git check-ignore hello #outputs nothing\n>> echo $?  #shows correct exit status=1 i.e None of the provided paths are ignored.\n>> but\n>> git check-ignore -v hello #output is next line\n>> .gitignore:4:!hello   hello\n>> echo $?  #shows wrong exit status=0 i.e. One or more of the provided paths is ignored\n\n>Hmph.  This is kind of understandable given the history of the\n>command, which was *not* about programatically ask \"is this path\n>ignored?\" question at all.  Instead, it was invented to answer this\n>question: I am puzzled by the fact that Git considers this path is\n>to be ignored (or \"not to be ignored\").  Show me which entry in what\n>exclude file made the final decision to ignore (or \"not to ignore\")\n>it to help me debug my ignore file(s).\n\n>And the exit code was to signal \"yes, I found a relevant entry\",\n>which made sense for the tool's nature as a debugging aid.\n\nman git-check-ignore states:-\nEXIT STATUS\n-----------\n0::\n\tOne or more of the provided paths is ignored.\n1::\n\tNone of the provided paths are ignored.\n128::\n\tA fatal error was encountered.\n\nSo my change matches what the manual states.\n\n>So, I suspect that this is working as designed/intended.  I agree\n>that it is debatable that the way it was designed to work is a good\n>one, though.\n\nI doubt that changing the exit status when -v is added is intended behaviour."},{"id":"423270","messageId":"CY4P132MB0088FC0DEE457E49EA21266F855F9@CY4P132MB0088.NAMP132.PROD.OUTLOOK.COM","threadId":"55570","inReplyTo":"3ea4e4c8-9723-4af6-5f07-9141c3001986@gmail.com","subject":"Re: bug:git-check-ignore exit status is wrong for negative patterns when -v option used","fromName":"Jeremy Faith","fromEmail":"jeremy.faith@jci.com","sentAt":"2021-04-29T14:26:38Z","receivedAt":"2021-04-29T14:26:40Z","isPatch":false,"sender":{"key":"jeremy.faith@jci.com","avatar":null},"body":"on 28 April 2021 07:15 Bagas Sanjaya wrote:\n \n>On 27/04/21 23.30, Jeremy Faith wrote:\n>> Hi,\n>> \n>> git version 2.31.1.362.g311531c9de\n>> git-check-ignore\n>> When a negative pattern is the last .gitignore match the -v option causes the exit status to be 0 rather than the expected 1.\n>> e.g say .gitignore contains  one line: !hello\n>> git check-ignore hello #outputs nothing\n>> echo $?  #shows correct exit status=1 i.e None of the provided paths are ignored.\n>> but\n>> git check-ignore -v hello #output is next line\n>> .gitignore:4:!hello   hello\n>> echo $?  #shows wrong exit status=0 i.e. One or more of the provided paths is ignored\n>> \n>> Following change seems to fix it for me\n>> --- a/builtin/check-ignore.c\n>> +++ b/builtin/check-ignore.c\n>> @@ -114,7 +114,7 @@ static int check_ignore(struct dir_struct *dir,\n>>                  }\n>>                  if (!quiet && (pattern || show_non_matching))\n>>                          output_pattern(pathspec.items[i].original, pattern);\n>> -               if (pattern)\n>> +               if (pattern && !(pattern->flags & PATTERN_FLAG_NEGATIVE))\n>>                          num_ignored++;\n>>          }\n>>          free(seen);\n \n>I tried to apply this patch from the mbox, but it was corrupted, so I had to\n>manually write the changes above. I tested that with your reproduction case and\n>it worked as expected.\n\n>But anyway, please send the proper patch and (preferentially) with the test\n>consisting of the reproduction case.\n\n>Thanks.\n\nSorry I just posted the output of 'git diff' previously but I cut off the first 2 lines by mistake.\nI'm not sure what is required as a test script.\n\ndiff --git a/builtin/check-ignore.c b/builtin/check-ignore.c\nindex 3c652748d5..223cc6a1ef 100644\n--- a/builtin/check-ignore.c\n+++ b/builtin/check-ignore.c\n@@ -114,7 +114,7 @@ static int check_ignore(struct dir_struct *dir,\n }\n if (!quiet && (pattern || show_non_matching))\n output_pattern(pathspec.items[i].original, pattern);\n- if (pattern)\n+ if (pattern && !(pattern->flags & PATTERN_FLAG_NEGATIVE))\n num_ignored++;\n }\n free(seen);"},{"id":"423306","messageId":"xmqq5z04fwoz.fsf@gitster.g","threadId":"55570","inReplyTo":"CY4P132MB00885F00AAA46BCFAC76881B855F9@CY4P132MB0088.NAMP132.PROD.OUTLOOK.COM","subject":"Re: bug:git-check-ignore exit status is wrong for negative patterns when -v option used","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-30T00:22:20Z","receivedAt":"2021-04-30T00:22:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeremy Faith writes:\n\n> man git-check-ignore states:-\n> EXIT STATUS\n> -----------\n> 0::\n> \tOne or more of the provided paths is ignored.\n> 1::\n> \tNone of the provided paths are ignored.\n> 128::\n> \tA fatal error was encountered.\n>\n> So my change matches what the manual states.\n\nThat is part of what I meant by \"understandable, given the history\".\n\nThe above description is _wrong_ ever since it was introduced, along\nwith check-ignore, at 368aa529 (add git-check-ignore sub-command,\n2013-01-06). It should have said \"has/have entry that affects it in\nthe gitignore/exclude files\" instead of \"is/are ignored\". After\nall, that is what the tool was written to do, i.e. to help debugging\nthe gitignore/exclude files.\n\n git-check-ignore(1)\n ===================\n\n NAME\n ----\n git-check-ignore - Debug gitignore / exclude files\n\nHaving said all that.\n\nIt is a misunderstanding that check-ignore is a tool to learn if a\npath is or is not ignored, but the misunderstanding is so widespread.\n\nI wonder if we can repurpose the command to \"match\" the\nmisunderstanding, without hurting existing users, by\n\n (1) updating the one-liner description of the command in the\n documentation;\n\n (2) keep the EXIT STATUS section as-is; and\n\n (3) adjust the code to exit with status that reflects if there was\n at least one path that was ignored (not \"that had an entry in\n the gitignore/exclude files that affected its fate\").\n\nThat certainly is a backward compatible change, but I suspect that\nwe may be able to sell it as a bugfix, taking advantage of the\ndocumentation bug you quoted above. Of course, people do not read\ndocumentation, so scripts that used to use the command in the way it\nwas intended to be used (as opposed to \"the way it was documented\")\nwill still get broken with such a change, though.\n\n\n"},{"id":"423328","messageId":"CY4P132MB00883DC8ABC72790A15C9630855E9@CY4P132MB0088.NAMP132.PROD.OUTLOOK.COM","threadId":"55570","inReplyTo":"xmqq5z04fwoz.fsf@gitster.g","subject":"Re: bug:git-check-ignore exit status is wrong for negative patterns when -v option used","fromName":"Jeremy Faith","fromEmail":"jeremy.faith@jci.com","sentAt":"2021-04-30T09:56:11Z","receivedAt":"2021-04-30T09:56:24Z","isPatch":false,"sender":{"key":"jeremy.faith@jci.com","avatar":null},"body":"On 30 April 2021 01:22 Junio C Hamano wrote:\n\n>Jeremy Faith writes:\n>\n>> man git-check-ignore states:-\n>> EXIT STATUS\n>> -----------\n>> 0::\n>> One or more of the provided paths is ignored.\n>> 1::\n>> None of the provided paths are ignored.\n>> 128::\n>> A fatal error was encountered.\n>>\n>> So my change matches what the manual states.\n\n>That is part of what I meant by \"understandable, given the history\".\n\n>The above description is _wrong_ ever since it was introduced, along\n>with check-ignore, at 368aa529 (add git-check-ignore sub-command,\n>2013-01-06). It should have said \"has/have entry that affects it in\n>the gitignore/exclude files\" instead of \"is/are ignored\". After\n>all, that is what the tool was written to do, i.e. to help debugging\n>the gitignore/exclude files.\n>\n> git-check-ignore(1)\n> ===================\n>\n> NAME\n> ----\n> git-check-ignore - Debug gitignore / exclude files\n>\n>Having said all that.\n>\n>It is a misunderstanding that check-ignore is a tool to learn if a\n>path is or is not ignored, but the misunderstanding is so widespread.\n>\n>I wonder if we can repurpose the command to \"match\" the\n>misunderstanding, without hurting existing users, by\n>\n> (1) updating the one-liner description of the command in the\n> documentation;\n\n> (2) keep the EXIT STATUS section as-is; and\n>\n> (3) adjust the code to exit with status that reflects if there was\n> at least one path that was ignored (not \"that had an entry in\n> the gitignore/exclude files that affected its fate\").\n\nIf I understand correctly:-\n (2) requires no change\n (3) I believe my one line change does this\n\nWhich just leaves (1) where current line is\n git-check-ignore - Debug gitignore / exclude files\nI think with the exit status operating as documented this description still\nworks i.e. check-ignore can be used to test if the .gitignore/exclude files\nare working as desired.\n\nThe longer Description is:\n DESCRIPTION\n For each pathname given via the command-line or from a file via\n --stdin, check whether the file is excluded by .gitignore (or other\n input files to the exclude mechanism) and output the path if it is\n excluded.\nWhich matches the exit status meaning as is.\n\n>That certainly is a backward compatible change, but I suspect that\n>we may be able to sell it as a bugfix, taking advantage of the\n>documentation bug you quoted above. Of course, people do not read\n>documentation, so scripts that used to use the command in the way it\n>was intended to be used (as opposed to \"the way it was documented\")\n>will still get broken with such a change, though.\n\nI'm not sure how the old exit status could be used in a useful way but you are\ncorrect there is a chance that some existing scripts depend on it.\n\nI was originally confused by the exit status when using git versions 1.8.3.1\nand 2.25.1. With these versions check-ignore returned 0 when a matching\npattern was found, it did not matter if it was a positive or negative pattern.\nThis did not match the exit status documented in the man page so I thought my\n.gitignore patterns were not working when they were.\nPerhaps I should stop reading man pages...\n\nI then tried the same patterns on an up to date version of git built from a\na git clone and found that without -v it returned the exit status as the man\npage states but with -v the older exit status was given.\nThe commit that changed the exit status was 7ec8125 from 2020-02-18, first\nrelease that included this commit was 2.26.\n\nSo in 2.26 the exit status without -v was changed, maybe accidentally, in a\nway that made it match the man page. But this commit broke scripts(that\ndo not use -v) that depend on exit status. My change extends the breakage to\nscripts that do use -v. On the other hand scripts written that expect the\nexit status to match the man page will be fixed!\n\nI'm not sure what the best course of action is but at least with my change\nthe exit status matches the man page(even with -v)."},{"id":"423374","messageId":"CABPp-BHYTBq=ExL=wx5oPH+DmWpSxsTqMbiOHgMM8uF1czs49g@mail.gmail.com","threadId":"55570","inReplyTo":"CY4P132MB00883DC8ABC72790A15C9630855E9@CY4P132MB0088.NAMP132.PROD.OUTLOOK.COM","subject":"Re: bug:git-check-ignore exit status is wrong for negative patterns when -v option used","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-04-30T20:51:18Z","receivedAt":"2021-04-30T20:51:35Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Apr 30, 2021 at 2:57 AM Jeremy Faith wrote:\n>\n> On 30 April 2021 01:22 Junio C Hamano wrote:\n>\n> >Jeremy Faith writes:\n> >\n> >> man git-check-ignore states:-\n> >> EXIT STATUS\n> >> -----------\n> >> 0::\n> >> One or more of the provided paths is ignored.\n> >> 1::\n> >> None of the provided paths are ignored.\n> >> 128::\n> >> A fatal error was encountered.\n> >>\n> >> So my change matches what the manual states.\n>\n> >That is part of what I meant by \"understandable, given the history\".\n>\n> >The above description is _wrong_ ever since it was introduced, along\n> >with check-ignore, at 368aa529 (add git-check-ignore sub-command,\n> >2013-01-06). It should have said \"has/have entry that affects it in\n> >the gitignore/exclude files\" instead of \"is/are ignored\". After\n> >all, that is what the tool was written to do, i.e. to help debugging\n> >the gitignore/exclude files.\n> >\n> > git-check-ignore(1)\n> > ===================\n> >\n> > NAME\n> > ----\n> > git-check-ignore - Debug gitignore / exclude files\n> >\n> >Having said all that.\n> >\n> >It is a misunderstanding that check-ignore is a tool to learn if a\n> >path is or is not ignored, but the misunderstanding is so widespread.\n> >\n> >I wonder if we can repurpose the command to \"match\" the\n> >misunderstanding, without hurting existing users, by\n> >\n> > (1) updating the one-liner description of the command in the\n> > documentation;\n>\n> > (2) keep the EXIT STATUS section as-is; and\n> >\n> > (3) adjust the code to exit with status that reflects if there was\n> > at least one path that was ignored (not \"that had an entry in\n> > the gitignore/exclude files that affected its fate\").\n>\n> If I understand correctly:-\n> (2) requires no change\n> (3) I believe my one line change does this\n>\n> Which just leaves (1) where current line is\n> git-check-ignore - Debug gitignore / exclude files\n> I think with the exit status operating as documented this description still\n> works i.e. check-ignore can be used to test if the .gitignore/exclude files\n> are working as desired.\n>\n> The longer Description is:\n> DESCRIPTION\n> For each pathname given via the command-line or from a file via\n> --stdin, check whether the file is excluded by .gitignore (or other\n> input files to the exclude mechanism) and output the path if it is\n> excluded.\n> Which matches the exit status meaning as is.\n>\n> >That certainly is a backward compatible change, but I suspect that\n> >we may be able to sell it as a bugfix, taking advantage of the\n> >documentation bug you quoted above. Of course, people do not read\n> >documentation, so scripts that used to use the command in the way it\n> >was intended to be used (as opposed to \"the way it was documented\")\n> >will still get broken with such a change, though.\n>\n> I'm not sure how the old exit status could be used in a useful way but you are\n> correct there is a chance that some existing scripts depend on it.\n>\n> I was originally confused by the exit status when using git versions 1.8.3.1\n> and 2.25.1. With these versions check-ignore returned 0 when a matching\n> pattern was found, it did not matter if it was a positive or negative pattern.\n> This did not match the exit status documented in the man page so I thought my\n> .gitignore patterns were not working when they were.\n> Perhaps I should stop reading man pages...\n>\n> I then tried the same patterns on an up to date version of git built from a\n> a git clone and found that without -v it returned the exit status as the man\n> page states but with -v the older exit status was given.\n> The commit that changed the exit status was 7ec8125 from 2020-02-18, first\n> release that included this commit was 2.26.\n>\n> So in 2.26 the exit status without -v was changed, maybe accidentally, in a\n> way that made it match the man page. But this commit broke scripts(that\n> do not use -v) that depend on exit status. My change extends the breakage to\n> scripts that do use -v. On the other hand scripts written that expect the\n> exit status to match the man page will be fixed!\n>\n> I'm not sure what the best course of action is but at least with my change\n> the exit status matches the man page(even with -v).\n\nI'm inclined to agree with Jeremy here. Commit 7ec8125fba96\n(check-ignore: fix documentation and implementation to match,\n2020-02-18) demonstrated pretty clearly that check-ignore was just\nflat-out broken since the beginning in regards to negated patterns, in\nmultiple ways: wrong exit status, documentation that was\nself-contradictory, and non-matching documentation and implementation.\nAmong other things, that commit from last year fixed the exit status\nwithout -v. Unfortunately, when I (or the users I was interacting\nwith) use -v, I ignore the exit status and am just looking for the\noutput. So I missed the exit status inconsistency for -v when I\ncreated that commit and only fixed the exit status without -v.\n"},{"id":"423457","messageId":"xmqqo8dsa4y8.fsf@gitster.g","threadId":"55570","inReplyTo":"CY4P132MB00883DC8ABC72790A15C9630855E9@CY4P132MB0088.NAMP132.PROD.OUTLOOK.COM","subject":"Re: bug:git-check-ignore exit status is wrong for negative patterns when -v option used","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-03T03:09:35Z","receivedAt":"2021-05-03T03:09:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeremy Faith writes:\n\n>>I wonder if we can repurpose the command to \"match\" the\n>>misunderstanding, without hurting existing users, by\n>>\n>> (1) updating the one-liner description of the command in the\n>> documentation;\n>\n>> (2) keep the EXIT STATUS section as-is; and\n>>\n>> (3) adjust the code to exit with status that reflects if there was\n>> at least one path that was ignored (not \"that had an entry in\n>> the gitignore/exclude files that affected its fate\").\n>\n> If I understand correctly:-\n> (2) requires no change\n> (3) I believe my one line change does this\n>\n> Which just leaves (1) where current line is\n> git-check-ignore - Debug gitignore / exclude files\n> I think with the exit status operating as documented this description still\n> works i.e. check-ignore can be used to test if the .gitignore/exclude files\n> are working as desired.\n\nAs an end-user facing command, we'd probably want to align this more\nwith the description of check-attr. I think that the description as\nyou quoted is OK as-is.\n\n>>That certainly is a backward compatible change, but I suspect that\n>>we may be able to sell it as a bugfix, taking advantage of the\n>>documentation bug you quoted above. Of course, people do not read\n>>documentation, so scripts that used to use the command in the way it\n>>was intended to be used (as opposed to \"the way it was documented\")\n>>will still get broken with such a change, though.\n>\n> I'm not sure how the old exit status could be used in a useful way but you are\n> correct there is a chance that some existing scripts depend on it.\n\nI have a suspicion that the existing tests may depend on the current\n\"we found a match\" semantics---they may not count as \"existing\nscripts\". We'd need to update them if that is the case.\n\n> I was originally confused by the exit status when using git versions 1.8.3.1\n> and 2.25.1. With these versions check-ignore returned 0 when a matching\n> pattern was found, it did not matter if it was a positive or negative pattern.\n> This did not match the exit status documented in the man page so I thought my\n> .gitignore patterns were not working when they were.\n\nYup, that is understandable as the manpage was utterly wrong, and\nits description was so plausible that nobody noticed.\n\nAs I already said, I think it is OK to sell this change as a bugfix\nto align implementation with the documentation wrt negative results;\nin addition to the 3 item list quoted at the top, we might need to\nadjust tests (or add tests if we are not covering the \"not excluded\nbecause we explicitly have a negative entry\" case).\n\nThanks.\n\n\n\n\n"}]}