On Mon, Dec 14, 2009 at 09:21:06PM +0530, Sitaram Chamarty wrote: > Before b5227d8, the following two commands would produce different > outputs (say on git.git): > > git ls-files > git ls-files -x '*.c' > > From b5227d8 onward, they produce the same output. The second command > no longer excludes *.c files. > > I was unable to understand the commit message completely but it sounds > like this was intentionally changed to do this. Yes, it was intentional. Excludes are about untracked files, not about restricting parts of the index. The point of the change was to bring "ls-files" in harmony with other parts of git. For example, prior to b5227d8, you could do: $ git init $ echo content >file && git add . && git commit -m base $ echo changes >file $ echo file >.gitignore $ git ls-files --exclude-standard -m <no output> $ git diff-files --name-only file But both "ls-files --exclude-standard" and "diff-files" should produce the same list (and they do post-b5227d8). However, for your use case, I can see the utility of an option to limit the output of ls-files for a particular invocation. It's just that "-x" is tied into the excludes mechanism, which doesn't do that. I would not be opposed to a patch to add an option that means "exclude these index entries from the output list." And for the sake of backwards compatibility, it may even be reasonable to call that option "-x". The change in b5227d8 was really about ls-files mis-using .gitignore and .git/info/exclude; people providing "-x" for a particular invocation probably want to limit everything. -Peff -- 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