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

From: Jeff King <peff@peff.net>
Date: Dec 14, 2009, 18:25 UTC
Message-ID: <20091214182420.GA31594@coredump.intra.peff.net>
In-Reply-To: <2e24e5b90912140751y5d769f15pa6782914bdb04dbd@mail.gmail.com>

On Mon, Dec 14, 2009 at 09:21:06PM +0530, Sitaram Chamarty wrote:

Show 11 quoted lines

> 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