* How to find out which gitignore blocks my git-add @ 2009-02-06 9:38 Gonzo 2009-02-06 19:33 ` Jeff King 2009-02-06 22:00 ` Bisani, Alok 0 siblings, 2 replies; 17+ messages in thread From: Gonzo @ 2009-02-06 9:38 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to find out which gitignore blocks my git-add 2009-02-06 9:38 How to find out which gitignore blocks my git-add Gonzo @ 2009-02-06 19:33 ` Jeff King 2009-02-07 1:33 ` Sitaram Chamarty 2009-02-06 22:00 ` Bisani, Alok 1 sibling, 1 reply; 17+ messages in thread From: Jeff King @ 2009-02-06 19:33 UTC (permalink / raw) To: Gonzo; +Cc: git On Fri, Feb 06, 2009 at 10:38:45AM +0100, Gonzo wrote: > 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? No, I don't think so. > Would this be a viable addition to "git add -v"? 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to find out which gitignore blocks my git-add 2009-02-06 19:33 ` Jeff King @ 2009-02-07 1:33 ` Sitaram Chamarty 2009-02-07 6:42 ` Jeff King 0 siblings, 1 reply; 17+ messages in thread From: Sitaram Chamarty @ 2009-02-07 1:33 UTC (permalink / raw) To: git On 2009-02-06, Jeff King <peff@peff.net> wrote: > On Fri, Feb 06, 2009 at 10:38:45AM +0100, Gonzo wrote: >> Is there an easy way to find out which line in which gitignore file >> blocks this add? > > No, I don't think so. > >> Would this be a viable addition to "git add -v"? > > 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. maybe GIT_TRACE could print that as well, in some way? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to find out which gitignore blocks my git-add 2009-02-07 1:33 ` Sitaram Chamarty @ 2009-02-07 6:42 ` Jeff King 2009-02-07 6:44 ` [PATCH 1/2] refactor exclude handling Jeff King ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Jeff King @ 2009-02-07 6:42 UTC (permalink / raw) To: Sitaram Chamarty; +Cc: git On Sat, Feb 07, 2009 at 01:33:43AM +0000, Sitaram Chamarty wrote: > > 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. > > maybe GIT_TRACE could print that as well, in some way? 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 1/2] refactor exclude handling 2009-02-07 6:42 ` Jeff King @ 2009-02-07 6:44 ` Jeff King 2009-02-07 6:44 ` [PATCH 2/2] give exclude mechanism a debug option Jeff King 2009-02-07 12:44 ` How to find out which gitignore blocks my git-add Sitaram Chamarty 2 siblings, 0 replies; 17+ messages in thread From: Jeff King @ 2009-02-07 6:44 UTC (permalink / raw) To: Sitaram Chamarty; +Cc: git 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(-) diff --git a/dir.c b/dir.c index cfd1ea5..0ea81b7 100644 --- a/dir.c +++ b/dir.c @@ -291,9 +291,10 @@ static void prep_exclude(struct dir_struct *dir, const char *base, int baselen) } /* Scan the list and let the last match determines the fate. - * Return 1 for exclude, 0 for include and -1 for undecided. + * Returns the exclude_list element which matched, or NULL for + * undecided. */ -static int excluded_1(const char *pathname, +static struct exclude *excluded_1(const char *pathname, int pathlen, const char *basename, int *dtype, struct exclude_list *el) { @@ -303,7 +304,6 @@ static int excluded_1(const char *pathname, for (i = el->nr - 1; 0 <= i; i--) { struct exclude *x = el->excludes[i]; const char *exclude = x->pattern; - int to_exclude = x->to_exclude; if (x->flags & EXC_FLAG_MUSTBEDIR) { if (*dtype == DT_UNKNOWN) @@ -316,14 +316,14 @@ static int excluded_1(const char *pathname, /* match basename */ if (x->flags & EXC_FLAG_NOWILDCARD) { if (!strcmp(exclude, basename)) - return to_exclude; + return x; } else if (x->flags & EXC_FLAG_ENDSWITH) { if (x->patternlen - 1 <= pathlen && !strcmp(exclude + 1, pathname + pathlen - x->patternlen + 1)) - return to_exclude; + return x; } else { if (fnmatch(exclude, basename, 0) == 0) - return to_exclude; + return x; } } else { @@ -342,16 +342,16 @@ static int excluded_1(const char *pathname, if (x->flags & EXC_FLAG_NOWILDCARD) { if (!strcmp(exclude, pathname + baselen)) - return to_exclude; + return x; } else { if (fnmatch(exclude, pathname+baselen, FNM_PATHNAME) == 0) - return to_exclude; + return x; } } } } - return -1; /* undecided */ + return NULL; } int excluded(struct dir_struct *dir, const char *pathname, int *dtype_p) @@ -363,8 +363,11 @@ int excluded(struct dir_struct *dir, const char *pathname, int *dtype_p) prep_exclude(dir, pathname, basename-pathname); for (st = EXC_CMDL; st <= EXC_FILE; st++) { - switch (excluded_1(pathname, pathlen, basename, - dtype_p, &dir->exclude_list[st])) { + struct exclude *x = excluded_1(pathname, pathlen, basename, + dtype_p, &dir->exclude_list[st]); + if (!x) + continue; + switch (x->to_exclude) { case 0: return 0; case 1: -- 1.6.1.2.552.g1682c.dirty ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 2/2] give exclude mechanism a debug option 2009-02-07 6:42 ` Jeff King 2009-02-07 6:44 ` [PATCH 1/2] refactor exclude handling Jeff King @ 2009-02-07 6:44 ` Jeff King 2009-02-07 7:38 ` Junio C Hamano 2009-02-07 12:44 ` How to find out which gitignore blocks my git-add Sitaram Chamarty 2 siblings, 1 reply; 17+ messages in thread From: Jeff King @ 2009-02-07 6:44 UTC (permalink / raw) To: Sitaram Chamarty; +Cc: git 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(-) diff --git a/dir.c b/dir.c index 0ea81b7..1052496 100644 --- a/dir.c +++ b/dir.c @@ -8,6 +8,7 @@ #include "cache.h" #include "dir.h" #include "refs.h" +#include "quote.h" struct path_simplify { int len; @@ -354,6 +355,24 @@ static struct exclude *excluded_1(const char *pathname, return NULL; } +static int debug_ignore(void) +{ + static int ignore = -1; + if (ignore == -1) { + const char *env = getenv("GIT_DEBUG_IGNORE"); + ignore = env ? git_config_bool("GIT_DEBUG_IGNORE", env) : 0; + } + return ignore; +} + +static void show_ignore(const char *path, struct exclude *x) +{ + quote_c_style(path, NULL, stderr, 0); + fprintf(stderr, ": %s: %.*s\n", + (x->to_exclude ? "exclude" : "include"), + x->patternlen, x->pattern); +} + int excluded(struct dir_struct *dir, const char *pathname, int *dtype_p) { int pathlen = strlen(pathname); @@ -367,6 +386,8 @@ int excluded(struct dir_struct *dir, const char *pathname, int *dtype_p) dtype_p, &dir->exclude_list[st]); if (!x) continue; + if (debug_ignore()) + show_ignore(pathname, x); switch (x->to_exclude) { case 0: return 0; -- 1.6.1.2.552.g1682c.dirty ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] give exclude mechanism a debug option 2009-02-07 6:44 ` [PATCH 2/2] give exclude mechanism a debug option Jeff King @ 2009-02-07 7:38 ` Junio C Hamano 2009-02-07 7:42 ` Junio C Hamano 2009-02-07 11:44 ` Jeff King 0 siblings, 2 replies; 17+ messages in thread From: Junio C Hamano @ 2009-02-07 7:38 UTC (permalink / raw) To: Jeff King; +Cc: Sitaram Chamarty, git Jeff King <peff@peff.net> 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. . ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] give exclude mechanism a debug option 2009-02-07 7:38 ` Junio C Hamano @ 2009-02-07 7:42 ` Junio C Hamano 2009-02-07 11:46 ` Jeff King 2009-02-07 11:44 ` Jeff King 1 sibling, 1 reply; 17+ messages in thread From: Junio C Hamano @ 2009-02-07 7:42 UTC (permalink / raw) To: Jeff King; +Cc: Sitaram Chamarty, git Junio C Hamano <gitster@pobox.com> writes: >> 1. Doing it as a debug environment variable is hack-ish. >> A nicer interface would be a .gitignore equivalent of >> "git check-attr". > > Correct. 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] give exclude mechanism a debug option 2009-02-07 7:42 ` Junio C Hamano @ 2009-02-07 11:46 ` Jeff King 0 siblings, 0 replies; 17+ messages in thread From: Jeff King @ 2009-02-07 11:46 UTC (permalink / raw) To: Junio C Hamano; +Cc: Sitaram Chamarty, git On Fri, Feb 06, 2009 at 11:42:45PM -0800, Junio C Hamano wrote: > Junio C Hamano <gitster@pobox.com> writes: > > >> 1. Doing it as a debug environment variable is hack-ish. > >> A nicer interface would be a .gitignore equivalent of > >> "git check-attr". > > > > Correct. > > 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? 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] give exclude mechanism a debug option 2009-02-07 7:38 ` Junio C Hamano 2009-02-07 7:42 ` Junio C Hamano @ 2009-02-07 11:44 ` Jeff King 2009-02-07 21:45 ` Junio C Hamano 1 sibling, 1 reply; 17+ messages in thread From: Jeff King @ 2009-02-07 11:44 UTC (permalink / raw) To: Junio C Hamano; +Cc: Sitaram Chamarty, git On Fri, Feb 06, 2009 at 11:38:38PM -0800, Junio C Hamano wrote: > > 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? 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] give exclude mechanism a debug option 2009-02-07 11:44 ` Jeff King @ 2009-02-07 21:45 ` Junio C Hamano 2009-02-08 8:59 ` Jeff King 0 siblings, 1 reply; 17+ messages in thread From: Junio C Hamano @ 2009-02-07 21:45 UTC (permalink / raw) To: Jeff King; +Cc: Sitaram Chamarty, git Jeff King <peff@peff.net> writes: > On Fri, Feb 06, 2009 at 11:38:38PM -0800, Junio C Hamano wrote: > >> > 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? > > 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. 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? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] give exclude mechanism a debug option 2009-02-07 21:45 ` Junio C Hamano @ 2009-02-08 8:59 ` Jeff King 2009-02-08 9:50 ` Junio C Hamano 0 siblings, 1 reply; 17+ messages in thread From: Jeff King @ 2009-02-08 8:59 UTC (permalink / raw) To: Junio C Hamano; +Cc: Sitaram Chamarty, git On Sat, Feb 07, 2009 at 01:45:44PM -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. > > Sorry, I do not understand why you need the downstream pipe that filters > using grep to begin with. 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. > 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 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] give exclude mechanism a debug option 2009-02-08 8:59 ` Jeff King @ 2009-02-08 9:50 ` Junio C Hamano 2009-02-08 9:52 ` Jeff King 0 siblings, 1 reply; 17+ messages in thread From: Junio C Hamano @ 2009-02-08 9:50 UTC (permalink / raw) To: Jeff King; +Cc: Sitaram Chamarty, git Jeff King <peff@peff.net> writes: > On Sat, Feb 07, 2009 at 01:45:44PM -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. >> >> Sorry, I do not understand why you need the downstream pipe that filters >> using grep to begin with. > > 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. 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." ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] give exclude mechanism a debug option 2009-02-08 9:50 ` Junio C Hamano @ 2009-02-08 9:52 ` Jeff King 0 siblings, 0 replies; 17+ messages in thread From: Jeff King @ 2009-02-08 9:52 UTC (permalink / raw) To: Junio C Hamano; +Cc: Sitaram Chamarty, git On Sun, Feb 08, 2009 at 01:50:27AM -0800, Junio C Hamano wrote: > 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: *~ 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to find out which gitignore blocks my git-add 2009-02-07 6:42 ` Jeff King 2009-02-07 6:44 ` [PATCH 1/2] refactor exclude handling Jeff King 2009-02-07 6:44 ` [PATCH 2/2] give exclude mechanism a debug option Jeff King @ 2009-02-07 12:44 ` Sitaram Chamarty 2009-02-07 13:31 ` Jeff King 2 siblings, 1 reply; 17+ messages in thread From: Sitaram Chamarty @ 2009-02-07 12:44 UTC (permalink / raw) To: git On 2009-02-07, Jeff King <peff@peff.net> wrote: > 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. 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... ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to find out which gitignore blocks my git-add 2009-02-07 12:44 ` How to find out which gitignore blocks my git-add Sitaram Chamarty @ 2009-02-07 13:31 ` Jeff King 0 siblings, 0 replies; 17+ messages in thread From: Jeff King @ 2009-02-07 13:31 UTC (permalink / raw) To: Sitaram Chamarty; +Cc: git On Sat, Feb 07, 2009 at 12:44:27PM +0000, Sitaram Chamarty wrote: > On 2009-02-07, Jeff King <peff@peff.net> wrote: > > 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. > > 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... 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: How to find out which gitignore blocks my git-add 2009-02-06 9:38 How to find out which gitignore blocks my git-add Gonzo 2009-02-06 19:33 ` Jeff King @ 2009-02-06 22:00 ` Bisani, Alok 1 sibling, 0 replies; 17+ messages in thread From: Bisani, Alok @ 2009-02-06 22:00 UTC (permalink / raw) To: git Gonzo <gonzo <at> gonsolo.de> writes: > > 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 > It would be nice if a -v option also lists which pattern caused it to exclude. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2009-02-08 9:53 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-02-06 9:38 How to find out which gitignore blocks my git-add Gonzo 2009-02-06 19:33 ` Jeff King 2009-02-07 1:33 ` Sitaram Chamarty 2009-02-07 6:42 ` Jeff King 2009-02-07 6:44 ` [PATCH 1/2] refactor exclude handling Jeff King 2009-02-07 6:44 ` [PATCH 2/2] give exclude mechanism a debug option Jeff King 2009-02-07 7:38 ` Junio C Hamano 2009-02-07 7:42 ` Junio C Hamano 2009-02-07 11:46 ` Jeff King 2009-02-07 11:44 ` Jeff King 2009-02-07 21:45 ` Junio C Hamano 2009-02-08 8:59 ` Jeff King 2009-02-08 9:50 ` Junio C Hamano 2009-02-08 9:52 ` Jeff King 2009-02-07 12:44 ` How to find out which gitignore blocks my git-add Sitaram Chamarty 2009-02-07 13:31 ` Jeff King 2009-02-06 22:00 ` Bisani, Alok
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).