Junio C Hamano <gits...@pobox.com> writes:
> Let's step back a bit and think what this command is about. What is
> the reason why the user wants to run "check-ignore $path" in the
> first place? I think there are two (or three, depending on how you
> (1) You have one (or more) paths at hand. You want to know if it
> is (or some of them are) ignored, but you do not particularly
> care how they are ignored. Think of implementing your own "git
> add" as a script.
> (2) You have one or more paths that are ignored but do not want
> them to be, and want to find out why they are.
A reason related to (2) is to find out why the paths you want to be
excluded are included, so that you can fix it by disabling an entry
in .gitignore that covers too widely, or by adding a new entry to
For that to work, the "-v" mode needs to show all paths that were
given from the command line (or --stdin), to explain why each of
them is ignored or not ignored. Hence, in addition:
> For the latter, you are debugging the set of exclude sources and
> want to learn where the decision to exclude it comes from. For that
> kind of use, it would be more useful if the output mimicked error
> messages from the compilers and output from "grep -n" to show the
> source, e.g.
> .gitignore:13:/git-am git-am
we would need an entry that shows !<include pattern> in the output.
A path that does not match any pattern anywhere in the exclude files
is taken as included---I am not sure what is the best way to explain
the reason why they are included. If we are going to show the entry
that finally matched (either with negative or positive pattern) and
decided the "fate" as the explanation for both excluded and included
paths, perhaps not showing an entry for such a "never matched" path
might be a good enough explanation.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html