Jeff King <peff@xxxxxxxx> writes: > Users can set GIT_DEBUG_IGNORE in the environment to get the > exclusion mechanism to dump to stderr files mentioned in > .gitignore along with the pattern that matched. The output > looks something like: > > foo.c: exclude: *.c > > This implementation has several shortcomings that make it > unsuitable for inclusion: > > 1. Doing it as a debug environment variable is hack-ish. > A nicer interface would be a .gitignore equivalent of > "git check-attr". Correct. > 2. If you ask for "foo/bar", and "foo/" is ignored, the > output will show only "foo: exclude: foo". This is an > artifact of the calling interface: you don't ask "is > foo/bar excluded", but rather while recursing through > "foo/" you ask "should I bother even recursing into > foo?". So the exclusion code never even knows that you > might have cared about foo/bar in the first place. I do not see why it is a problem. It exactly is what you want to know, isn't it? > 3. There is no indication of where patterns came from. We > could specify whether it came from the command-line, > from per-directory files, or from another file. But what > is most interesting is the actual _filename_ that it > came from. I.e., something like: > > sub/foo.c: exclude: sub/.gitignore: *.c > > But that information seems to have been forgotten by > the time we are actually doing excludes. For this, you would need to add an element to exclude_stack structure to record the human readable name of the exclude source in prep_exclude(). Once you find the matched element using your new excluded_1() mechanism introduced by patch 1/2, you can find which stack in dir->exclude_stack the match element belongs to, and map it back the human readable source name recorded in the exclude_stack. . -- 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
