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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 21, 2012, 16:27 UTC
Message-ID: <7vbogz8ho2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <505C15E4.7060108@alum.mit.edu>

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

Show 19 quoted lines

>> +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.