Junio C Hamano <gitster@xxxxxxxxx> 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 > count). > > (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 override it. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html