From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [RFD/PATCH] add: ignore only ignored files
Date: Thu, 20 Nov 2014 10:42:16 +0100 [thread overview]
Message-ID: <546DB778.2000000@drmicha.warpmail.net> (raw)
In-Reply-To: <xmqqbno2rhlz.fsf@gitster.dls.corp.google.com>
Junio C Hamano schrieb am 19.11.2014 um 22:43:
> Jeff King <peff@peff.net> writes:
>
>> 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".
>
> Yup. I also find myself doing "git cmd -- \*.ext" to let Git, not
> my shell, handle the patterns.
That is the correct way, of course.
>> 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.
>
> ;-)
>
You can simply say "Michael" in your last subclause above :)
I'm wondering whether that behaviour change (without --ignore-errors) is
OK - I don't mind, but hey, I usually don't.
I think it all comes down to the fact whether specifying an ignored file
on the command line is considered an error or only "possibly a user
error" we should dwim around. "git add" being plumbing, I'm somehow
hesitant to change behaviour unless git is asked to ignore error. And if
I'm hesitant already... oh wait. git add is declared porcelain? I would
not have guessed without looking it up.
Michael
next prev parent reply other threads:[~2014-11-20 9:42 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
2014-11-19 21:43 ` Junio C Hamano
2014-11-20 9:42 ` Michael J Gruber [this message]
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=546DB778.2000000@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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).