From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
To: Jay Soffian <jaysoffian@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git <git@vger.kernel.org>
Subject: Re: ls-files --exclude broken?
Date: Thu, 16 Sep 2010 09:29:58 +1000 [thread overview]
Message-ID: <AANLkTik7ORPUsABJv-bFraFNt2TvP0Xx=-013P2=A6Nr@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimYNtU7sHn4_Vx50evTWDpMK_=XgshU3ZzT+eVw@mail.gmail.com>
On Thu, Sep 16, 2010 at 9:19 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Wed, Sep 15, 2010 at 7:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> 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.
>
> Correct.
>
>>> 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).
>
> I want cached paths, minus the exclude pattern. Using -c -x \* gives
> the same result.
>
> There is no indication in the man page that -x doesn't apply to -c.
>
>>> 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.
>
> I don't care about -i myself, and maybe I should have been clearer.
> AFAICT, [-c] -x is broken:
>
> $ git ls-files -c -x \* |wc -l
> 2009
>
> -c, --cached
> Show cached files in the output (default)
>
> -x <pattern>, --exclude=<pattern>
> Skips files matching pattern. Note that pattern is a shell
> wildcard pattern.
>
> Oh, geez, here it is lower down in the man page:
>
> git ls-files can use a list of "exclude patterns" when traversing
> the directory tree and finding files to show when the flags --others
> or --ignored are specified. gitignore(5) specifies the format of
> exclude patterns.
>
> Bah, what use is that? Minimally ls-files shouldn't accept -x unless
> given either --ignored or --others if that's all it applies to. I
> guess this is my itch to scratch.
I sense another use of negative pathspecs here..
--
Duy
next prev parent reply other threads:[~2010-09-15 23:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 22:40 ls-files --exclude broken? Jay Soffian
2010-09-15 23:06 ` Nguyen Thai Ngoc Duy
2010-09-15 23:12 ` Junio C Hamano
2010-09-15 23:19 ` Jay Soffian
2010-09-15 23:29 ` Nguyen Thai Ngoc Duy [this message]
2010-09-15 23:41 ` Jay Soffian
2010-09-15 23:47 ` Jay Soffian
2010-09-16 0:16 ` Jeff King
2010-09-16 0:33 ` Jay Soffian
2010-09-16 0:50 ` Jeff King
2010-09-15 23:34 ` Elijah Newren
2010-09-15 23:21 ` Kevin Ballard
2010-09-15 23:31 ` Daniel Johnson
2010-09-15 23:56 ` [PATCH] git-ls-files.txt: clarify -x/--exclude option Jay Soffian
2010-09-16 0:19 ` Jeff King
2010-09-16 0:41 ` Junio C Hamano
2010-09-16 0:51 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTik7ORPUsABJv-bFraFNt2TvP0Xx=-013P2=A6Nr@mail.gmail.com' \
--to=pclouds@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jaysoffian@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).