{"thread":{"id":"30653","subject":"Bug: git ls-files and ignored directories","startedAt":"2012-05-30T10:22:18Z","lastAt":"2012-06-04T02:12:44Z","messageCount":13,"participants":["Christoph Buchner","Jeff King","Clemens Buchacher","Junio C Hamano","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"192470","messageId":"20120530102218.0625CFC006A@dd24126.kasserver.com","threadId":"30653","inReplyTo":null,"subject":"Bug: git ls-files and ignored directories","fromName":"Christoph Buchner","fromEmail":"bilderbuchi@phononoia.at","sentAt":"2012-05-30T10:22:18Z","receivedAt":"2012-05-30T10:22:18Z","isPatch":false,"sender":{"key":"bilderbuchi@phononoia.at","avatar":null},"body":"Hi!\n\nI think I've been bitten by a bug in git ls-files - committed directories (and files therein) which are matched by a \"dir/\" gitignore rule are not shown by \"git ls-files --exclude-standard -i\", although they should be. Matched files are shown.\n\nI've found a very brief discussion on this mailing list from March 2011 about this, including a repro procedure which still is valid today, at http://marc.info/?l=git&m=129926031808376&w=4\n\nIs that a known/in progress bug? If yes, (when) can a fix be expected? How can I work around this in the meantime? \nIf it's not a bug, how do you do this properly? My original problem was that  I want to list files which have been committed to git but match an existing gitignore pattern. Richard Hansen has written a very nice alias for that (http://stackoverflow.com/a/9370094/599884, with some discussion of this bug in the comments), but due to the present bug this does not work totally correctly. \n\nHaving a built-in git feature for this would be great, btw (\"git ls-files --committed-but-ignored\"? :-)). Do I have to submit a separate feature request?\n\nthanks, \nChristoph\n\np.s.: The repro procedure from the linked list discussion:\n> $ mkdir test\n> $ cd test\n> $ git init\n> $ mkdir testdir\n> $ touch testdir/test\n> $ git add testdir/test\n> $ git commit -m \"add test\"\n> $ echo \"testdir/\" > .gitignore\n> $ git ls-files --exclude-standard -i\n"},{"id":"192553","messageId":"20120531101451.C35C5B4C00D@dd24126.kasserver.com","threadId":"30653","inReplyTo":"20120530102218.0625CFC006A@dd24126.kasserver.com","subject":"Bug: git ls-files and ignored directories","fromName":"Christoph Buchner","fromEmail":"bilderbuchi@phononoia.at","sentAt":"2012-05-31T10:14:51Z","receivedAt":"2012-05-31T10:14:51Z","isPatch":false,"sender":{"key":"bilderbuchi@phononoia.at","avatar":null},"body":"This is the right place to report bugs, right?\nIs there any protocol to follow I'm not aware of, to enable you to process this bug report?\n\ngreets,\nChristoph\n\n----- Original Message -----\nFrom: bilderbuchi@phononoia.at\nTo: git@vger.kernel.org\nDate: 30.05.2012 12:22:18\nSubject: Bug: git ls-files and ignored directories\n\n\n> Hi!\n> \n> I think I've been bitten by a bug in git ls-files - committed directories (and files therein) which are matched by a \"dir/\" gitignore rule are not shown by \"git ls-files --exclude-standard -i\", although they should be. Matched files are shown.\n> \n> I've found a very brief discussion on this mailing list from March 2011 about this, including a repro procedure which still is valid today, at http://marc.info/?l=git&m=129926031808376&w=4\n> \n> Is that a known/in progress bug? If yes, (when) can a fix be expected? How can I work around this in the meantime? \n> If it's not a bug, how do you do this properly? My original problem was that  I want to list files which have been committed to git but match an existing gitignore pattern. Richard Hansen has written a very nice alias for that (http://stackoverflow.com/a/9370094/599884, with some discussion of this bug in the comments), but due to the present bug this does not work totally correctly. \n> \n> Having a built-in git feature for this would be great, btw (\"git ls-files --committed-but-ignored\"? :-)). Do I have to submit a separate feature request?\n> \n> thanks, \n> Christoph\n> \n> p.s.: The repro procedure from the linked list discussion:\n>> $ mkdir test\n>> $ cd test\n>> $ git init\n>> $ mkdir testdir\n>> $ touch testdir/test\n>> $ git add testdir/test\n>> $ git commit -m \"add test\"\n>> $ echo \"testdir/\" > .gitignore\n>> $ git ls-files --exclude-standard -i\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"192643","messageId":"20120601093757.GE32340@sigill.intra.peff.net","threadId":"30653","inReplyTo":"20120531101451.C35C5B4C00D@dd24126.kasserver.com","subject":"Re: Bug: git ls-files and ignored directories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-06-01T09:37:57Z","receivedAt":"2012-06-01T09:37:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 31, 2012 at 12:14:51PM +0200, Christoph Buchner wrote:\n\n> This is the right place to report bugs, right?\n\nYes.\n\n> Is there any protocol to follow I'm not aware of, to enable you to\n> process this bug report?\n\nNot really. You send the report, and you may or may not get a response\n(just as you may or may not have somebody respond to you in a bug\ntracker).  Probably nobody has had a chance to look at it yet. If there\nis a history to the bug (which there is in this case), it is sometimes\nhelpful to cc the previous participants to see if they are still\ninterested in it.\n\n> > I think I've been bitten by a bug in git ls-files - committed\n> > directories (and files therein) which are matched by a \"dir/\"\n> > gitignore rule are not shown by \"git ls-files --exclude-standard\n> > -i\", although they should be. Matched files are shown.\n> > \n> > I've found a very brief discussion on this mailing list from March\n> > 2011 about this, including a repro procedure which still is valid\n> > today, at http://marc.info/?l=git&m=129926031808376&w=4\n> > \n> > Is that a known/in progress bug? If yes, (when) can a fix be\n> > expected? How can I work around this in the meantime?\n\nNo, I don't think anybody is working on it at the moment (at least I\ndo not see anything near the time of that old discussion, nor do I\nrecall it being discussed since).\n\n+cc Clemens, in case he had any work-in-progress as a result that did\nnot end up getting published.\n\n-Peff\n"},{"id":"192669","messageId":"20120601153002.GA13233@ecki","threadId":"30653","inReplyTo":"20120601093757.GE32340@sigill.intra.peff.net","subject":"Re: Bug: git ls-files and ignored directories","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-06-01T15:30:03Z","receivedAt":"2012-06-01T15:30:03Z","isPatch":false,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Fri, Jun 01, 2012 at 05:37:57AM -0400, Jeff King wrote:\n> \n> +cc Clemens, in case he had any work-in-progress as a result that did\n> not end up getting published.\n\nUnfortunately, I don't recall this bug at all. I probably don't have a\nfix for it either.\n"},{"id":"192670","messageId":"7vr4tz3tpw.fsf@alter.siamese.dyndns.org","threadId":"30653","inReplyTo":"20120601093757.GE32340@sigill.intra.peff.net","subject":"Re: Bug: git ls-files and ignored directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-01T16:03:23Z","receivedAt":"2012-06-01T16:03:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> No, I don't think anybody is working on it at the moment (at least I\n> do not see anything near the time of that old discussion, nor do I\n> recall it being discussed since).\n>\n> +cc Clemens, in case he had any work-in-progress as a result that did\n> not end up getting published.\n\nI think the way the codepath for -i feeds path to excluded() is wrong.\n\nThe excluded() interface relies on the fact that the caller has\nalready checked foo/ before calling it for foo/bar; when asked to\nsee if \"foo/bar\" is excluded, it does not consider if \"foo/\" is\nexcluded---the caller should have already checked it.\n\nThe loop for cached/stage case in builtin/ls-files.c::show_files()\nneeds to learn to be more careful when DIR_SHOW_IGNORED is set in\ndir->flags.  It needs to call a new helper function that notices\nthat the check is walking into a different directory from the path\nit checked last, and feed leading directories to excluded(), or\nsomething like that, instead of directly calling !excluded().\n"},{"id":"192682","messageId":"7vipfa3n0v.fsf@alter.siamese.dyndns.org","threadId":"30653","inReplyTo":"7vr4tz3tpw.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: git ls-files and ignored directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-01T18:28:00Z","receivedAt":"2012-06-01T18:28:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jeff King <peff@peff.net> writes:\n>\n>> No, I don't think anybody is working on it at the moment (at least I\n>> do not see anything near the time of that old discussion, nor do I\n>> recall it being discussed since).\n>>\n>> +cc Clemens, in case he had any work-in-progress as a result that did\n>> not end up getting published.\n>\n> I think the way the codepath for -i feeds path to excluded() is wrong.\n>\n> The excluded() interface relies on the fact that the caller has\n> already checked foo/ before calling it for foo/bar; when asked to\n> see if \"foo/bar\" is excluded, it does not consider if \"foo/\" is\n> excluded---the caller should have already checked it.\n>\n> The loop for cached/stage case in builtin/ls-files.c::show_files()\n> needs to learn to be more careful when DIR_SHOW_IGNORED is set in\n> dir->flags.  It needs to call a new helper function that notices\n> that the check is walking into a different directory from the path\n> it checked last, and feed leading directories to excluded(), or\n> something like that, instead of directly calling !excluded().\n\nA naive and unoptimized implementation may look like this patch.\n\nThe \"path_exclude_check\" structure can be enhanced to record the\nleading directory it has last checked to be known to be excluded so\nthat path_excluded() can check if the ce->name[] is still inside\nthat directory and return true early, but I'll leave it as an\nexercise for interested readers while I look at other topics for the\nupcoming release.\n\n-- >8 --\nSubject: ls-files -i: pay attention to exclusion of leading paths\n\n\"git ls-files --exclude=t/ -i\" does not show paths in directory t/\nthat have been added to the index, but it should.\n\nThe excluded() API was designed for callers who walk the tree from\nthe top, checking each level of the directory hierarchy as it\ndescends if it is excluded, and not even bothering to recurse into\nan excluded directory.  This would allow us optimize for a common\ncase by not having to check if the exclude pattern \"foo/\" matches\nwhen looking at \"foo/bar\", because the caller should have noticed\nthat \"foo\" is excluded and did not even bother to read \"foo/bar\"\nout of opendir()/readdir() to call it.\n\nThe code for \"ls-files -i\" however walks the index linearly, feeding\npaths without checking if the leading directory is already excluded.\n\nIntroduce a helper function path_excluded() to let this caller\nproperly call excluded() check for higher hierarchies as necessary.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n builtin/ls-files.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++------\n 1 file changed, 49 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin/ls-files.c b/builtin/ls-files.c\nindex 7cff175..40f8865 100644\n--- a/builtin/ls-files.c\n+++ b/builtin/ls-files.c\n@@ -13,6 +13,7 @@\n #include \"parse-options.h\"\n #include \"resolve-undo.h\"\n #include \"string-list.h\"\n+#include \"strbuf.h\"\n \n static int abbrev;\n static int show_deleted;\n@@ -200,9 +201,50 @@ static void show_ru_info(void)\n \t}\n }\n \n+struct path_exclude_check {\n+\tstruct dir_struct *dir;\n+\tstruct strbuf path;\n+};\n+\n+static void path_exclude_check_init(struct path_exclude_check *check,\n+\t\t\t\t    struct dir_struct *dir)\n+{\n+\tcheck->dir = dir;\n+\tstrbuf_init(&check->path, 256);\n+}\n+\n+static void path_exclude_check_clear(struct path_exclude_check *check)\n+{\n+\tstrbuf_release(&check->path);\n+}\n+\n+static int path_excluded(struct path_exclude_check *check, struct cache_entry *ce)\n+{\n+\tint i, dtype;\n+\tstruct strbuf *path = &check->path;\n+\tstrbuf_setlen(path, 0);\n+\n+\tfor (i = 0; ce->name[i]; i++) {\n+\t\tint ch = ce->name[i];\n+\n+\t\tif (ch == '/') {\n+\t\t\tdtype = DT_DIR;\n+\t\t\tif (excluded(check->dir, path->buf, &dtype))\n+\t\t\t\treturn 1;\n+\t\t}\n+\t\tstrbuf_addch(path, ch);\n+\t}\n+\tdtype = ce_to_dtype(ce);\n+\treturn excluded(check->dir, ce->name, &dtype);\n+}\n+\n static void show_files(struct dir_struct *dir)\n {\n \tint i;\n+\tstruct path_exclude_check check;\n+\n+\tif ((dir->flags & DIR_SHOW_IGNORED))\n+\t\tpath_exclude_check_init(&check, dir);\n \n \t/* For cached/deleted files we don't need to even do the readdir */\n \tif (show_others || show_killed) {\n@@ -215,9 +257,8 @@ static void show_files(struct dir_struct *dir)\n \tif (show_cached | show_stage) {\n \t\tfor (i = 0; i < active_nr; i++) {\n \t\t\tstruct cache_entry *ce = active_cache[i];\n-\t\t\tint dtype = ce_to_dtype(ce);\n-\t\t\tif (dir->flags & DIR_SHOW_IGNORED &&\n-\t\t\t    !excluded(dir, ce->name, &dtype))\n+\t\t\tif ((dir->flags & DIR_SHOW_IGNORED) &&\n+\t\t\t    !path_excluded(&check, ce))\n \t\t\t\tcontinue;\n \t\t\tif (show_unmerged && !ce_stage(ce))\n \t\t\t\tcontinue;\n@@ -232,9 +273,8 @@ static void show_files(struct dir_struct *dir)\n \t\t\tstruct cache_entry *ce = active_cache[i];\n \t\t\tstruct stat st;\n \t\t\tint err;\n-\t\t\tint dtype = ce_to_dtype(ce);\n-\t\t\tif (dir->flags & DIR_SHOW_IGNORED &&\n-\t\t\t    !excluded(dir, ce->name, &dtype))\n+\t\t\tif ((dir->flags & DIR_SHOW_IGNORED) &&\n+\t\t\t    !path_excluded(&check, ce))\n \t\t\t\tcontinue;\n \t\t\tif (ce->ce_flags & CE_UPDATE)\n \t\t\t\tcontinue;\n@@ -247,6 +287,9 @@ static void show_files(struct dir_struct *dir)\n \t\t\t\tshow_ce_entry(tag_modified, ce);\n \t\t}\n \t}\n+\n+\tif ((dir->flags & DIR_SHOW_IGNORED))\n+\t\tpath_exclude_check_clear(&check);\n }\n \n /*\n"},{"id":"192687","messageId":"7vvcja25ye.fsf@alter.siamese.dyndns.org","threadId":"30653","inReplyTo":"7vipfa3n0v.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: git ls-files and ignored directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-01T19:22:01Z","receivedAt":"2012-06-01T19:22:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> A naive and unoptimized implementation may look like this patch.\n>\n> The \"path_exclude_check\" structure can be enhanced to record the\n> leading directory it has last checked to be known to be excluded so\n> that path_excluded() can check if the ce->name[] is still inside\n> that directory and return true early, but I'll leave it as an\n> exercise for interested readers while I look at other topics for the\n> upcoming release.\n\nAnd an obvious and simple optimization would look like this.\n\nWe can keep the shallowest of the excluded directory (i.e. where a\ntraversing caller would have stopped recursing) in check->path, and\nkeep returning \"Yes, it is excluded\" as long as the path is inside\nthat directory.\n\n builtin/ls-files.c | 18 ++++++++++++++++++\n 1 file changed, 18 insertions(+)\n\ndiff --git a/builtin/ls-files.c b/builtin/ls-files.c\nindex 1385852..5beada0 100644\n--- a/builtin/ls-files.c\n+++ b/builtin/ls-files.c\n@@ -218,11 +218,25 @@ static void path_exclude_check_clear(struct path_exclude_check *check)\n \tstrbuf_release(&check->path);\n }\n \n+/*\n+ * Is the ce->name excluded?  This is for a caller like show_files() that\n+ * do not honor directory hierarchy and iterate through paths that are\n+ * possibly in an ignored directory.\n+ *\n+ * A path to a directory known to be excluded is left in check->path to\n+ * optimize for repeated checks for files in the same excluded directory.\n+ */\n static int path_excluded(struct path_exclude_check *check, struct cache_entry *ce)\n {\n \tint i, dtype;\n \tstruct strbuf *path = &check->path;\n \n+\tif (path->len &&\n+\t    path->len <= ce_namelen(ce) &&\n+\t    !memcmp(ce->name, path->buf, path->len) &&\n+\t    (!ce->name[path->len] || ce->name[path->len] == '/'))\n+\t\treturn 1;\n+\n \tstrbuf_setlen(path, 0);\n \tfor (i = 0; ce->name[i]; i++) {\n \t\tint ch = ce->name[i];\n@@ -234,6 +248,10 @@ static int path_excluded(struct path_exclude_check *check, struct cache_entry *c\n \t\t}\n \t\tstrbuf_addch(path, ch);\n \t}\n+\n+\t/* An entry in the index; cannot be a directory with subentries */\n+\tstrbuf_setlen(path, 0);\n+\n \tdtype = ce_to_dtype(ce);\n \treturn excluded(check->dir, ce->name, &dtype);\n }\n"},{"id":"192707","messageId":"CACsJy8CqMudg=uKuDmRHoYAXhUoYhOp3V2ZLuKM8W5wWWE460w@mail.gmail.com","threadId":"30653","inReplyTo":"7vr4tz3tpw.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: git ls-files and ignored directories","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-06-02T10:33:55Z","receivedAt":"2012-06-02T10:33:55Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Jun 1, 2012 at 11:03 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> No, I don't think anybody is working on it at the moment (at least I\n>> do not see anything near the time of that old discussion, nor do I\n>> recall it being discussed since).\n>>\n>> +cc Clemens, in case he had any work-in-progress as a result that did\n>> not end up getting published.\n>\n> I think the way the codepath for -i feeds path to excluded() is wrong.\n>\n> The excluded() interface relies on the fact that the caller has\n> already checked foo/ before calling it for foo/bar; when asked to\n> see if \"foo/bar\" is excluded, it does not consider if \"foo/\" is\n> excluded---the caller should have already checked it.\n\nSparse checkout deals with the exact same problem and it reconstructs\na tree structure from cache list, before feeding to excluded(). I\nthought of generalizing it (e.g. for this case), but with v5 in\nprogress, we'll probably have tree-based index soon. \"ls-files -i\"\ncould be fixed by then.\n-- \nDuy\n"},{"id":"192710","messageId":"4FC9F24D.7000306@phononoia.at","threadId":"30653","inReplyTo":"CACsJy8CqMudg=uKuDmRHoYAXhUoYhOp3V2ZLuKM8W5wWWE460w@mail.gmail.com","subject":"Bug: git ls-files and ignored directories","fromName":"Christoph Buchner","fromEmail":"bilderbuchi@phononoia.at","sentAt":"2012-06-02T11:00:29Z","receivedAt":"2012-06-02T11:00:29Z","isPatch":false,"sender":{"key":"bilderbuchi@phononoia.at","avatar":null},"body":"@Jeff: Thank you for the clarification. I didn't want to appear pushy, I \njust wanted to make sure that I did everything right and that my mail \nwon't get ignored/filtered because of some breach of protocol.\n\n@Junio, Duy: Thanks for starting/proposing work on this!\n\nthanks,\nChristoph\n\nOn 06/02/2012 12:33 PM, Nguyen Thai Ngoc Duy wrote:\n> On Fri, Jun 1, 2012 at 11:03 PM, Junio C Hamano<gitster@pobox.com>  wrote:\n>> Jeff King<peff@peff.net>  writes:\n>>\n>>> No, I don't think anybody is working on it at the moment (at least I\n>>> do not see anything near the time of that old discussion, nor do I\n>>> recall it being discussed since).\n>>>\n>>> +cc Clemens, in case he had any work-in-progress as a result that did\n>>> not end up getting published.\n>> I think the way the codepath for -i feeds path to excluded() is wrong.\n>>\n>> The excluded() interface relies on the fact that the caller has\n>> already checked foo/ before calling it for foo/bar; when asked to\n>> see if \"foo/bar\" is excluded, it does not consider if \"foo/\" is\n>> excluded---the caller should have already checked it.\n> Sparse checkout deals with the exact same problem and it reconstructs\n> a tree structure from cache list, before feeding to excluded(). I\n> thought of generalizing it (e.g. for this case), but with v5 in\n> progress, we'll probably have tree-based index soon. \"ls-files -i\"\n> could be fixed by then.\n"},{"id":"192732","messageId":"7vr4txz5j9.fsf@alter.siamese.dyndns.org","threadId":"30653","inReplyTo":"4FC9F24D.7000306@phononoia.at","subject":"Re: Bug: git ls-files and ignored directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-02T22:56:58Z","receivedAt":"2012-06-02T22:56:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christoph Buchner <bilderbuchi@phononoia.at> writes:\n\n> @Jeff: Thank you for the clarification. I didn't want to appear pushy,\n> I just wanted to make sure that I did everything right and that my\n> mail won't get ignored/filtered because of some breach of protocol.\n>\n> @Junio, Duy: Thanks for starting/proposing work on this!\n\nThe patches are queued to 'pu'.  Do they fix your issue?\n"},{"id":"192752","messageId":"4FCB4E1E.2010907@phononoia.at","threadId":"30653","inReplyTo":"7vr4txz5j9.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: git ls-files and ignored directories","fromName":"Christoph Buchner","fromEmail":"bilderbuchi@phononoia.at","sentAt":"2012-06-03T11:44:30Z","receivedAt":"2012-06-03T11:44:30Z","isPatch":false,"sender":{"key":"bilderbuchi@phononoia.at","avatar":null},"body":"Yes they do.\nIn my test repo, git compiled from current pu branch shows\ngit ls-files --exclude-standard -i\napps/devApps/projectGenerator/.svn/wrongly-committed-svn.txt\napps/devApps/projectGenerator/some-wrong-file.txt\nwhile git 1.7.9.5 shows\napps/devApps/projectGenerator/some-wrong-file.txt\n\nThank you for fixing this! Which git release is planned to contain the \nfix (if that can be said yet)? I'm not familiar with your workflow..\n\nthx,\nchristoph\n\n(junio, sorry for sending the mail twice, I accidentally hit reply \ninstead of reply all)\n\nOn 06/03/2012 12:56 AM, Junio C Hamano wrote:\n> Christoph Buchner<bilderbuchi@phononoia.at>  writes:\n>\n>> @Jeff: Thank you for the clarification. I didn't want to appear pushy,\n>> I just wanted to make sure that I did everything right and that my\n>> mail won't get ignored/filtered because of some breach of protocol.\n>>\n>> @Junio, Duy: Thanks for starting/proposing work on this!\n> The patches are queued to 'pu'.  Do they fix your issue?\n"},{"id":"192777","messageId":"7vwr3ovxsp.fsf@alter.siamese.dyndns.org","threadId":"30653","inReplyTo":"4FCB4E1E.2010907@phononoia.at","subject":"Re: Bug: git ls-files and ignored directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-03T22:24:38Z","receivedAt":"2012-06-03T22:24:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christoph Buchner <bilderbuchi@phononoia.at> writes:\n\n[please do not top-post]\n\n> On 06/03/2012 12:56 AM, Junio C Hamano wrote:\n>\n>> The patches are queued to 'pu'.  Do they fix your issue?\n> \n> Yes they do.\n> In my test repo, git compiled from current pu branch shows\n> git ls-files --exclude-standard -i\n> apps/devApps/projectGenerator/.svn/wrongly-committed-svn.txt\n> apps/devApps/projectGenerator/some-wrong-file.txt\n> while git 1.7.9.5 shows\n> apps/devApps/projectGenerator/some-wrong-file.txt\n>\n> Thank you for fixing this! Which git release is planned to contain the\n> fix (if that can be said yet)? I'm not familiar with your workflow..\n\nAs we are already in \"regression fix only\" phase, it won't be in the\nupcoming 1.7.11 series, even though it may deserve to be in 1.7.11.2\nmaintenance release.\n\nI see other uses of excluded() in builtin/add.c and unpack-trees.c;\nthese call sites need to be audited.\n\nIf they have the same problem, it probably is a good idea to convert\nthem to use path_excluded(), move the path_excluded() function and\nits supporting infrastructure from builtin/ls-files.c to dir.c, and\nmake excluded() a file-static function to dir.c in order to avoid\nsimilar problems in the future.  Or their use may be alright.\n\nThe work described in the previous paragraph preferrably should\nhappen before the change is shipped as part of any release.\n"},{"id":"192786","messageId":"7vmx4jvn8j.fsf@alter.siamese.dyndns.org","threadId":"30653","inReplyTo":"7vwr3ovxsp.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: git ls-files and ignored directories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-06-04T02:12:44Z","receivedAt":"2012-06-04T02:12:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> As we are already in \"regression fix only\" phase, it won't be in the\n> upcoming 1.7.11 series, even though it may deserve to be in 1.7.11.2\n> maintenance release.\n>\n> I see other uses of excluded() in builtin/add.c and unpack-trees.c;\n> these call sites need to be audited.\n>\n> If they have the same problem, it probably is a good idea to convert\n> them to use path_excluded(), move the path_excluded() function and\n> its supporting infrastructure from builtin/ls-files.c to dir.c, and\n> make excluded() a file-static function to dir.c in order to avoid\n> similar problems in the future.  Or their use may be alright.\n>\n> The work described in the previous paragraph preferrably should\n> happen before the change is shipped as part of any release.\n\nI've moved the path_excluded() stuff to dir.[ch] and queued the\nresult to 'pu', but didn't look at other uses of excluded().\n\nJust in case somebody is interested in working on it further.\n"}]}