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

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

[Sitaram Chamarty]

Hello,

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.

I've never been real clear on ls-files, and was wondering if someone
would be able to clarify the various ways of using it, including why
this change was made and is there a way (using some other combination of
flags perhaps) to get a list of files without *.c (to continue this
example).

Thanks,

Sitaram

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

[Michael J Gruber]

Sitaram Chamarty venit, vidit, dixit 14.12.2009 16:51:
> Hello,
> 
> 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. Generally, git commands never ignore tracked files, and this patch
reintroduces this for git ls-files

> I've never been real clear on ls-files, and was wondering if someone
> would be able to clarify the various ways of using it, including why
> this change was made and is there a way (using some other combination of
> flags perhaps) to get a list of files without *.c (to continue this
> example).

You can still use file glob patterns as the file argument, such as

git ls-files '*.[^c]'


Michael

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

[Jeff King]

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

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

[Sitaram Chamarty]

On Mon, Dec 14, 2009 at 11:55 PM, Jeff King <peff@peff.net> wrote:
> 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

OK; makes sense -- thanks for the explanation.

> 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

I rather doubt if my C skills extend that far these days; I'll figure out
other ways of doing this if I need it :-)

Thanks again,

Sitaram