On Sep 15, 2010, at 4:12 PM, Junio C Hamano wrote: > Jay Soffian <jaysoffian@xxxxxxxxx> writes: > >> Am I missing something really obvious here? >> >> kore:~/Repos/git (master)$ git ls-files | wc -l >> 2009 > > You asked it to show the cached paths (default). Your project currently > tracks 2009 paths in the index. > >> kore:~/Repos/git (master)$ git ls-files -x \* | wc -l >> 2009 > > You told that '*' is the exclude pattern for carrying out some operation, > but you didn't tell what operation you want. You are shown the cached > paths (default). > >> kore:~/Repos/git (master)$ git ls-files -i -x \* | wc -l >> 2009 > > You told that '*' is the exclude pattern, you want only paths that match > the exclude pattern, and chose to show files in the index (which again is > the default) by not saying -o. > > I've never found -i useful myself (actually I don't find many options the > command has very useful anymore), but the above is how I read the ls-files > manual page. My impression is that -x is pretty much only useful when you're using the -o flag, as anything that's already tracked isn't supposed to be affected by exclude patterns. The argument can be made that ls-files should indeed apply the exclude pattern to other requested display modes, and in fact a reading of the -i switch seems to imply that it should. Running `git ls-files -x '*.m' -c -i` displays all files ending in .m in the index. It would seem logical that the similar `git ls-files -x '*.m' -c` should display all files that don't end in .m in the index, but it doesn't appear to apply the exclude pattern in this case. As for -i being useful, I've never actually used it myself (though obviously it can be used as a way to grep through the index via the exclude pattern), but I can imagine a scenario where I want to clean up all untracked files and end up running something like `git ls-files -z -o -i --exclude-standard | xargs -0 rm`. -Kevin Ballard-- 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