Re: Expected behavior of "git check-ignore"...

From: Philip Oakley <philipoakley@iee.org>
Date: Jul 23, 2017, 16:33 UTC
Message-ID: <1E42613B0CD743C6ADA24B9F1B43F0F9@PhilipOakley>
In-Reply-To: <CAEBDL5URsbMazLBy-kWLJzECTEQ=61DN07xuu5NaO2Hw6r=j+w@mail.gmail.com>

From: "John Szakmeister" <john@szakmeister.net>
Sent: Thursday, July 20, 2017 11:37 AM

Show 10 quoted lines

>A StackOverflow user posted a question about how to reliably check
> whether a file would be ignored by "git add" and expected "git
> check-ignore" to return results that matched git add's behavior.  It
> turns out that it doesn't.  If there is a negation rule, we end up
> returning that exclude and printing it and exiting with 0 (there are
> some ignored files) even though the file has been marked to not be
> ignored.
>
> Is the expected behavior of "git check-ignore" to return 0 even if the
> file is not ignore when a negation is present?

I'm testing this on.. $ git --version

git version 2.10.0.windows.1

Show 5 quoted lines

>
>>>>>
> git init .
> echo 'foo/*' > .gitignore
> echo '!foo/bar' > .gitignore

Is this missing the >> append to get the full two line .gitignore? adding in a `cat .gitignore` would help check.

> mkdir foo
> touch foo/bar

I don't think you need these. It's the given pathnames that are checked, not the file system content.

> git check-ignore foo/bar

Does this need the `-q` option to set the exit status?

echo $? # to display the status.

Show 9 quoted lines

> <<<<
>
> I expect the last command to return 1 (no files are ignored), but it
> doesn't.  The StackOverflow user had the same expectation, and imagine
> others do as well.  OTOH, it looks like the command is really meant to
> be a debugging tool--to show me the line in a .gitignore associated
> with this file, if there is one.  In which case, the behavior is
> correct but the return code description is a bit misleading (0 means
> the file is ignored, which isn't true here).

Maybe the logic isn't that clear? Maybe it is simply detecting if any one of the ignore lines is active, and doesn't reset the status for a negation?

I appear to get the same response as yourself, but I haven't spent much time on it - I'm clearing a backlog of work at the moment.

I also tried the -v -n options, and if I swap the ignore lines around it still says line 2 is the one that ignores. It gets more interesting if two paths are given `foo/bar foo/baz`, to see which line picks up which pathname (and with the swapped ignore lines).

Is there a test for this in the test suite?

Show 10 quoted lines

>
> Thoughts?  It seems like this question was asked before several years
> ago but didn't get a response.
>
> Thanks!
>
> -John
>
> PS The SO question is here:
> https://stackoverflow.com/questions/45210790/how-to-reliably-check-whether-a-file-is-ignored-by-git

-- Philip