Re: BUG: git-check-ignore documentation doesn't come close to describing what it really does

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> I suspect we're having an aliasing problem that you're not
> recognizing.  "ignored" and "excluded" are used interchangeably, note
> that patterns from the $GIT_DIR/info/exclude files and patterns from
> the file pointed to by core.excludesFile are also lumped together with
> the patterns from all the .gitignore files (see the gitignore manual
> page).  Further, the internal code refers to them all as "excludes"
> not as "ignores".

All true.

> Yes, it outputs the paths that are excluded, as the documentation
> said.  Perhaps there's a way to reword it to make this clearer?  I
> don't think we can get rid of the alias given the fact that
> $GIT_DIR/info/exclude and core.excludesFile are hard-coded and must be
> kept for backward compatibility.  But suggestions to improve the
> wording would be great.
>
> Maybe it'd be as simple as replacing "is excluded" with "matches an
> ignore/exclude rule"?

I smell a continuation of 7ec8125f (check-ignore: fix documentation
and implementation to match, 2020-02-18), which appears in 2.26 and
later (the way the negative entries in the ignore/exclude mechanism
gets handled has changed in Git 2.26, and the documentation has been
updated).

"Is excluded" is perfectly fine, I think.  The first use of that
verb in the documentation should be a bit more careful, e.g. "is
excluded (aka ignored)" or something.

>> IMO the behavior of git-check-ignore is the correct and useful
>> behavior
>
> I'm with you here.

Yup, with the old "huh?" fixed in Git 2.26 (which was there simply
because check-ignore was not used to be a serious end-user facing
program but was more of a debugging aid), I think the behaviour of
the command we have today is what we want.

>> and the documentation should simply be fixed
>
> Yes, I agree it's easy to misinterpret.  Would my suggested changes help?
>
>> to reflect the
>> fact that it just lists matching entries rather than wrongly claiming
>> that it returns the overall result of the ignore calculation.
>
> I think I understood where the problems were in the documentation that
> could lead to misinterpretations in the other two cases you mentioned
> earlier in your email, but I don't understand this one.  Even the
> first sentence you quoted included the phrase that it could "output
> the path", so I'm not sure where you think it claims that it'd return
> the overall result of the ignore calculation.  Could you point out
> what in the document led you to believe it was claiming this?  Maybe I
> could suggest wording improvements for it as well.  Or maybe you have
> some.

It does return *the* matching entry that decided the path's fate.

    $ (echo '/no-such-*'; echo '!/no-such-*') >>.git/info/exclude
    $ git check-ignore -v no-such-directory; echo $?
    .git/info/exclude:14:!/no-such-*	no-such-directory
    0

Exit status section needs a bit more work.  It used to be OK to say
"success (0) is returned when we found a path that is ignored", but
these days, it is not whether there are ignored paths in the input.

It signals if we found an entry in the list of exclude/ignore
patterns that actively affects the path's fate.  In our project, if
we ask the fate of hello.c

    $ git check-itnore -v hello.c; echo $?
    1

because we do not say explicitly that .c files are usually tracked
sources.  If we did this:

    $ echo >>.git/info/exclude '!*.c'

to explicitly say that .c files are never ignored, it changes the
picture:

    $ git check-itnore -v hello.c; echo $?
    .git/info/exclude:15:!*.c	hello.c
    0