Re: b5227d8 changes meaning of "ls-files -x 'pattern'"

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