From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
Jakub Narebski <jnareb@gmail.com>,
Martin Langhoff <martin.langhoff@gmail.com>,
Michael J Gruber <git@drmicha.warpmail.net>,
git@vger.kernel.org
Subject: Re: [PATCH] add: introduce add.ignoreerrors synonym for add.ignore-errors
Date: Wed, 1 Dec 2010 16:07:42 -0500 [thread overview]
Message-ID: <20101201210742.GA13740@sigill.intra.peff.net> (raw)
In-Reply-To: <7vipzduufr.fsf@alter.siamese.dyndns.org>
On Wed, Dec 01, 2010 at 12:09:12PM -0800, Junio C Hamano wrote:
> We actually need to stress the fact that _only_ newer git will understand
> "add.ignoreErrors", so people with older git (especially the ones who need
> to use both older and newer versions of git) may need to keep using the
> older form in their configuration, no?
>
> Perhaps phrasing it like this, and then issue v1.7.{0,1,2,3}.X maintenance
> release to reduce the chance of inconveniencing the users?
Yeah, I think it is better to be explicit.
> add.ignore-errors::
> +add.ignoreErrors::
> Tells 'git add' to continue adding files when some files cannot be
> added due to indexing errors. Equivalent to the '--ignore-errors'
> - option of linkgit:git-add[1].
> + option of linkgit:git-add[1]. Older versions of git accept only
> + `add.ignore-errors`, whose name goes against the convention, so
> + newer versions of git honor `add.ignoreErrors` as well.
Nit: Somehow "goes against the convention" doesn't sound quite right to
me. Astute users can probably figure out which convention, but perhaps
we should be more explicit like:
Older versions of git accept only `add.ignore-errors`, which does not
follow the usual naming convention for configuration variable. Newer
versions of git honor `add.ignoreErrors` as well.
-Peff
next prev parent reply other threads:[~2010-12-01 21:07 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-25 15:10 [PATCH 1/3] cvsimport: partial whitespace cleanup Michael J Gruber
2010-11-25 15:10 ` [PATCH 2/3] cvsimport: fix the parsing of uppercase config options Michael J Gruber
2010-11-27 6:38 ` Junio C Hamano
2010-11-28 19:30 ` Michael J Gruber
2010-11-28 19:39 ` [PATCHv2 1/3] cvsimport: partial whitespace cleanup Michael J Gruber
2010-11-28 19:39 ` [PATCHv2 2/3] cvsimport: fix the parsing of uppercase config options Michael J Gruber
2010-11-28 19:39 ` [PATCHv2 3/3] cvsimport.txt: document the mapping between config and options Michael J Gruber
2010-11-29 20:23 ` Junio C Hamano
2010-11-30 7:56 ` Michael J Gruber
2010-12-01 1:43 ` Junio C Hamano
2010-12-01 12:53 ` [PATCHv3 0/3] uppercase config options for cvsimport Michael J Gruber
2010-12-01 12:53 ` [PATCHv3 1/3] cvsimport: partial whitespace cleanup Michael J Gruber
2010-12-01 12:53 ` [PATCHv3 2/3] cvsimport: fix the parsing of uppercase config options Michael J Gruber
2010-12-01 14:59 ` Martin Langhoff
2010-12-01 16:05 ` Jonathan Nieder
2010-12-01 16:18 ` Martin Langhoff
2010-12-01 16:23 ` Jakub Narebski
2010-12-01 16:34 ` Jonathan Nieder
2010-12-01 16:52 ` Michael J Gruber
2010-12-01 17:01 ` Jonathan Nieder
2010-12-01 17:58 ` Jeff King
2010-12-01 19:47 ` Junio C Hamano
2010-12-02 21:46 ` Junio C Hamano
2010-12-01 17:55 ` Jeff King
2010-12-01 18:36 ` [PATCH] add: introduce add.ignoreerrors synonym for add.ignore-errors Jonathan Nieder
2010-12-01 18:46 ` Jeff King
2010-12-01 18:57 ` Jonathan Nieder
2010-12-01 19:56 ` Junio C Hamano
2010-12-01 20:09 ` Junio C Hamano
2010-12-01 21:07 ` Jeff King [this message]
2010-12-03 2:18 ` Junio C Hamano
2010-12-01 12:53 ` [PATCHv3 3/3] cvsimport.txt: document the mapping between config and options Michael J Gruber
2010-12-01 15:02 ` [PATCHv2 " Martin Langhoff
2010-12-01 15:34 ` Michael J Gruber
2010-11-25 15:10 ` [PATCH " Michael J Gruber
2010-11-27 6:33 ` [PATCH 1/3] cvsimport: partial whitespace cleanup Junio C Hamano
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=20101201210742.GA13740@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=jrnieder@gmail.com \
--cc=martin.langhoff@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).