How to find out which gitignore blocks my git-add

After doing a "git add file" I get the message:

"The following paths are ignored by one of your .gitignore files: ..."

Is there an easy way to find out which line in which gitignore file blocks this add? Would this be a viable addition to "git add -v"?

g

On Fri, Feb 06, 2009 at 10:38:45AM +0100, Gonzo wrote:

No, I don't think so.

I think it might be useful to be able to get this information. However, rather than coupling it with "git add", it might make more sense to have a separate way to query "is this being ignored, and if so, by what pattern". Then you could use that tool to generally debug your .gitignore patterns.

I'm not sure how painful it would be to implement. You'd probably have to record and pass back that information from dir.c:excluded, which is where we decide whether or not a file is ignored (most of the code calls it "excluded", but it is the same concept). Want to take a stab at writing a patch?

-Peff

On 2009-02-06, Jeff King <peff@peff.net> wrote:

maybe GIT_TRACE could print that as well, in some way?

On Sat, Feb 07, 2009 at 01:33:43AM +0000, Sitaram Chamarty wrote:

It could, but I think reusing GIT_TRACE isn't a good idea. Currently it traces _just_ exec information, so I wouldn't want to pollute that with this information. But yes, you could trigger it through an environment variable, which would let us dump at the lowest level.

I spent a few minutes checking this out, and it looks to be a little more complex than I had hoped, just because we don't have all of the information in the same place at the same time.

A toy patch series follows; see 2/2 for a description of why it doesn't work like you might hope. I'm not too interested in trying to deal with the refactoring that would be required to do it right. But maybe somebody else is.

-Peff

The excluded function uses the static helper excluded_1 to perform the inner loop over all of the exclude patterns. The helper just tells us whether the path is included, excluded, or undecided.

However, it may be useful to know _which_ pattern was triggered. So let's pass out the entire exclude match, which contains the status information we were already passing out.

Further patches can make use of this.

Signed-off-by: Jeff King <peff@peff.net>
---
Just a cleanup for the next patch.

 dir.c |   25 ++++++++++++++-----------
 1 files changed, 14 insertions(+), 11 deletions(-)

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

  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.

  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.

Signed-off-by: Jeff King <peff@peff.net>
---
In addition to the problems above, this is hardly tested. ;)

 dir.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

Jeff King <peff@peff.net> writes:

Correct.

I do not see why it is a problem. It exactly is what you want to know, isn't it?

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

Junio C Hamano <gitster@pobox.com> writes:

I suspect that ls-files would be the good match for it. Wasn't the exclude mechanism originally done for that command to begin with?

On Fri, Feb 06, 2009 at 11:42:45PM -0800, Junio C Hamano wrote:

I think you are envisioning something like "which files are excluded, and what patterns matched them?" which ls-files is perhaps a good fit for. I was imagining something more like "which patterns are affecting this particular path?" which you could feed the output of a failed "git add" to.

-Peff

On Fri, Feb 06, 2009 at 11:38:38PM -0800, Junio C Hamano wrote:

Because I would expect "git check-ignore foo/bar | grep ^foo/bar:" to tell me if and how foo/bar is being excluded. But I have to instead check for ^foo and ^foo/bar.

Not a big deal, perhaps. But it just seems like counter-intuitive output for a query about how a specific path is excluded.

-Peff

Jeff King <peff@peff.net> writes:

Sorry, I do not understand why you need the downstream pipe that filters using grep to begin with.

Shouldn't "git check-ignore dir/path" talk about the exclude entries that caused dir/path to be excluded and no other patterns? And if the reason dir/path is exclude is because there was a higher level entry to exclude dir/, the output would say so. If there are unrelated exclude entries that exclude dir's neighbour dir2 or dir/path's neighbour dir/path2, they do not affect if dir/path is excluded, so check-ignore wouldn't show, no?

On Sat, Feb 07, 2009 at 01:45:44PM -0800, Junio C Hamano wrote:

Sorry, I should have been more clear. The grep was meant to simulate what my eyes and brain are doing. That is, if I ask "what are patterns affecting foo/bar?", I expect to see "foo/bar" in the output.

For asking about one path, it may not be that big a deal to see that the output matches to the input. But if I feed a hundred paths to check-ignore, I expect to be able to scan the output for the input I put in.

Yes, I would think so. Which maybe means using the current "exclude" code is not appropriate. Because it is really about traversing the directory structure, excluding as we go. I don't know that you can directly ask it about a particular path.

-Peff

Jeff King <peff@peff.net> writes:

Oh, then the output format would, just like "grep" given more than one file tells which file it found the match in, talk about which path the output entry talks about when given more than one path.

Something like:

	$ git check-ignore foo/bar xyzzy~ hello.c
	foo/bar: foo/.gitignore:4: ??r
        xyzzy~: .git/info/excludes:22: *~

that says "foo/bar is ignored because line 4 of foo/.gitignore tells us to ignore any three-letter filename that ends with r, xyzzy~ is ignored because .git/info/excludes tells us to ignore everything that ends with tilde on line 22, and hello.c is not ignored at all."

On Sun, Feb 08, 2009 at 01:50:27AM -0800, Junio C Hamano wrote:

Right, exactly. What I was trying to say in my original message was that my toy implementation _didn't_ do that, and it is a downside.

-Peff

On 2009-02-07, Jeff King <peff@peff.net> wrote:

I was thinking it could simply be a separate utility in contrib for starters, perhaps not even written in C. I don't mind volunteering to write one in shell+the usual toolchain (and I'll test it on msysgit too, because I have Windows users). My C days are a bit behind me, sadly...

On Sat, Feb 07, 2009 at 12:44:27PM +0000, Sitaram Chamarty wrote:

Sure, that might be an easy way to start. But in the long term, having a separate implementation handling .gitignore parsing and rules may diverge from what git is doing. OTOH, in theory those rules are pretty well set in stone since users are depending on them.

-Peff

Gonzo <gonzo <at> gonsolo.de> writes:

It would be nice if a -v option also lists which pattern caused
 it to exclude.