Re: [PATCH v2 14/14] Add git-check-ignore sub-command

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

Michael Haggerty <mhagger@alum.mit.edu> writes:

>> +For each pathname given via the command-line or from a file via
>> +`--stdin`, this command will list the first exclude pattern found (if
>> +any) which explicitly excludes or includes that pathname.  Note that
>> +within any given exclude file, later patterns take precedence over
>> +earlier ones, so any matching pattern which this command outputs may
>> +not be the one you would immediately expect.
>
> Can I tell from the output of "git check-ignore" whether a file is
> really ignored?  The way I read the paragraph above, the output doesn't
> necessarily show the pattern that determines whether a file is *really*
> ignored.  That makes it sound like the ignore status of the file might
> be different than what I would infer from the output.  If I am
> misunderstanding the situation, then perhaps the explanation in the
> above paragraph can be improved.
>
> On the other hand, if my understanding is correct, then why did you
> choose this (seemingly strange) policy?  It would seem more useful
> either to output the pattern that has the definitive effect on the
> file's status, or to output all patterns that match the file.

Very good point. I didn't look at this patch at all, but I would
guess the patch hooked this into the order in which the existing
ignore mechanism computes the match, and "the first I find" Adam
says is written from implementation point of view.

And that is a wrong way to go about it.

The existing document for the ignore mechanism explains things from
the end user perspective, i.e. within a file, the last matching
pattern determines the fate of the path.  And this debugging aid
should report which pattern from what source determined the fate of
the path, so from the end user perspective, saying "first" is
nonsense.

It just happens that the implementation optimizes by scanning the
list of patterns "backwards" and stops at the "first" hit, which is
the last matching pattern that determines the fate of the path.

The documentation of this debugging aid should use the same phrasing
"git help ignore" uses and say "show the pattern that decides the
outcome", and lose that confusing "Note that" that is not helping
anybody.