Hi!
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.
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
Is that a known/in progress bug? If yes, (when) can a fix be expected? How can I work around this in the meantime?
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.
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?
thanks,
Christoph
p.s.: The repro procedure from the linked list discussion:$ mkdir test
$ cd test
$ git init
$ mkdir testdir
$ touch testdir/test
$ git add testdir/test
$ git commit -m "add test"
$ echo "testdir/" > .gitignore
$ git ls-files --exclude-standard -i
This is the right place to report bugs, right?
Is there any protocol to follow I'm not aware of, to enable you to process this bug report?
greets,
Christoph
----- Original Message -----
From: bilderbuchi@phononoia.at
To: git@vger.kernel.org
Date: 30.05.2012 12:22:18
Subject: Bug: git ls-files and ignored directories
Hi!
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.
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
Is that a known/in progress bug? If yes, (when) can a fix be expected? How can I work around this in the meantime?
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.
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?
thanks,
Christoph
p.s.: The repro procedure from the linked list discussion:quoted
$ mkdir test
$ cd test
$ git init
$ mkdir testdir
$ touch testdir/test
$ git add testdir/test
$ git commit -m "add test"
$ echo "testdir/" > .gitignore
$ git ls-files --exclude-standard -i
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 31, 2012 at 12:14:51PM +0200, Christoph Buchner wrote:
This is the right place to report bugs, right?
Yes.
Is there any protocol to follow I'm not aware of, to enable you to
process this bug report?
Not really. You send the report, and you may or may not get a response
(just as you may or may not have somebody respond to you in a bug
tracker). Probably nobody has had a chance to look at it yet. If there
is a history to the bug (which there is in this case), it is sometimes
helpful to cc the previous participants to see if they are still
interested in it.
quoted
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.
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
Is that a known/in progress bug? If yes, (when) can a fix be
expected? How can I work around this in the meantime?
No, I don't think anybody is working on it at the moment (at least I
do not see anything near the time of that old discussion, nor do I
recall it being discussed since).
+cc Clemens, in case he had any work-in-progress as a result that did
not end up getting published.
-Peff
On Fri, Jun 01, 2012 at 05:37:57AM -0400, Jeff King wrote:
+cc Clemens, in case he had any work-in-progress as a result that did
not end up getting published.
Unfortunately, I don't recall this bug at all. I probably don't have a
fix for it either.