From: Jeff King <peff@peff.net>
To: Michael J Gruber <git@drmicha.warpmail.net>
Cc: git@vger.kernel.org
Subject: Re: [RFD/PATCH] add: ignore only ignored files
Date: Wed, 19 Nov 2014 14:15:02 -0500 [thread overview]
Message-ID: <20141119191502.GC9908@peff.net> (raw)
In-Reply-To: <3f78d6c1e35c87049daaac6cb1257ea8310a90bb.1416408015.git.git@drmicha.warpmail.net>
On Wed, Nov 19, 2014 at 03:52:33PM +0100, Michael J Gruber wrote:
> "git add foo bar" adds neither foo nor bar when bar is ignored, but dies
> to let the user recheck their command invocation. This becomes less
> helpful when "git add foo.*" is subject to shell expansion and some of
> the expanded files are ignored.
>
> "git add --ignore-errors" is supposed to ignore errors when indexing
> some files and adds the others. It does ignore errors from actual
> indexing attempts, but does not ignore the error "file is ignored" as
> outlined above.
>
> Change "git add --ignore-errors foo bar" to add foo when bar is ignored,
> i.e. to ignore the ignore error.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
FWIW, your complaint and this new behavior makes sense to me.
Typically I keep a very neat .gitignore file and just use "git add .",
which _does_ ignore those files. The real problem here is that git
cannot tell the difference between "the user explicitly asked for
foo.aux, so we should complain" and "oops, foo.aux got caught in a shell
expansion".
I almost wonder if skipping ignored files should _always_ be a warning,
not a hard error. I guess that has unpleasant side effects for scripts
which call "git add XXX" and check the exit code, who may be
unpleasantly surprised that they missed out on some content.
Perhaps we could do a hybrid: add the files that were not ignored, but
then still exit non-zero. Careful scripts need to check the exit status
of "git add" anyway, and sloppy humans with over-broad wildcards
typically do not care about the exit status.
-Peff
next prev parent reply other threads:[~2014-11-19 19:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 14:52 [RFD/PATCH] add: ignore only ignored files Michael J Gruber
2014-11-19 18:51 ` Junio C Hamano
2014-11-19 19:15 ` Jeff King [this message]
2014-11-19 21:43 ` Junio C Hamano
2014-11-20 9:42 ` Michael J Gruber
2014-11-20 15:56 ` Jeff King
2014-11-20 17:23 ` Junio C Hamano
2014-11-20 18:20 ` Jeff King
2014-11-21 15:39 ` Michael J Gruber
2014-11-21 16:08 ` [PATCHv2] " Michael J Gruber
2014-11-21 18:01 ` Jeff King
2014-11-22 14:59 ` Torsten Bögershausen
2014-11-22 19:19 ` Jeff King
2014-11-22 21:20 ` Torsten Bögershausen
2014-11-23 19:50 ` Jeff King
2014-11-23 18:10 ` Junio C Hamano
2014-11-23 19:46 ` Jeff King
2014-11-24 17:41 ` Junio C Hamano
2014-11-24 20:22 ` Torsten Bögershausen
2014-11-25 3:57 ` Jeff King
2014-11-24 10:29 ` Michael J Gruber
2014-11-24 10:23 ` Michael J Gruber
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=20141119191502.GC9908@peff.net \
--to=peff@peff.net \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
/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).