Re: ls-files --exclude broken?
On Sep 15, 2010, at 4:12 PM, Junio C Hamano wrote:
Show 27 quoted lines
> Jay Soffian <jaysoffian@gmail.com> 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
Kevin Ballard <kevin@sb.org>