From: Jeff King <peff@peff.net>
To: Jay Soffian <jaysoffian@gmail.com>
Cc: Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
Junio C Hamano <gitster@pobox.com>, git <git@vger.kernel.org>
Subject: Re: ls-files --exclude broken?
Date: Wed, 15 Sep 2010 20:50:24 -0400 [thread overview]
Message-ID: <20100916005024.GA3428@sigill.intra.peff.net> (raw)
In-Reply-To: <AANLkTikd5uZFk8-d7wmB8ZEqOy5=RWsDNnrsHqAQZhkz@mail.gmail.com>
On Wed, Sep 15, 2010 at 08:33:29PM -0400, Jay Soffian wrote:
> On Wed, Sep 15, 2010 at 8:16 PM, Jeff King <peff@peff.net> wrote:
> > It's not just the command line. It's also what's in .gitignore files. If
> > you disable just half of that, then you get the awful behavior that some
> > excludes apply to index files, and some don't.
>
> Files matched by the standard excludes are not likely to be in the
> index in the first place. So in that sense, arguably -x is special.
>
> But nonetheless, I agree with you, and since the user must
> specifically ask ls-files for the various exclusions, I think it makes
> sense to apply those even to cached files.
But then if somebody asks for both indexed and untracked files together,
the behavior is quite confusing. There is no way to say
"--exclude-standard just for the untracked files", and having exclusions
impact cached files is unlike any other part of git. So the behavior of
something like "git ls-files -s -o --exclude-standard" would be broken.
I have no idea if people are actually doing that.
So I think the best fix would be to leave the default behavior as-is,
and add the --exclude-cached-files-too-pretty-please you mentioned.
> I'm building a project file for my editor and I want to exclude
> certain files that make no sense for it to care about even though they
> are part of the repo. So I tried:
>
> $ git ls-files -x png -x jpg ...
>
> and was confused by that not working. I've worked around this by just
> filtering the ls-files output through grep, but, ick.
I certainly have sympathy for you being confused by the behavior of
ls-files. It undoubtedly is a mess.
But as for having to use grep, I would feel worse for you if you were
actually trying to exclude patterns from your .gitignore and you needed
to _convert_ them into a grep pattern. But it doesn't seem like:
git ls-files | grep -v '\.png$'
is really much more work, and it's way more flexible.
At one point I proposed a "git check-ignore" similar to "git
check-attr", but I never got around to coding it. If you really liked
the gitignore-style patterns for some reason, it would be a nice
flexible way of doing what you want.
-Peff
next prev parent reply other threads:[~2010-09-16 0:50 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
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 [this message]
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=20100916005024.GA3428@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jaysoffian@gmail.com \
--cc=pclouds@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).