From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively
Date: Wed, 29 Feb 2012 04:18:55 -0500 [thread overview]
Message-ID: <20120229091855.GE14181@sigill.intra.peff.net> (raw)
In-Reply-To: <7vy5rmt3w8.fsf@alter.siamese.dyndns.org>
On Wed, Feb 29, 2012 at 12:55:35AM -0800, Junio C Hamano wrote:
> > I can't imagine anybody would want to have different case-sensitivity
> > options for grepping the commit message versus pickaxe. But even if they
> > do, and we later add options to control them individually, we would
> > still want the short-and-sweet "-i" to cover the common case of setting
> > both. So I think the approach is good.
>
> What you didn't read in the above is that the devilq around "-i" is not in
> the case insensitivity switch between log-part grep (--grep/--author) and
> patch part grep (-S/-G), but how it interacts with generating the patch
> part case insensitively (i.e. "log -p --ignore-case", which is also "-i").
Hmm. So there are actually three potential options to flip. However, I
think the reasoning above is still sound. We could later split
--regexp-ignore-case into two sub-options if we wanted (but like I said,
I doubt anybody will want that; I was more concerned with making sure
that if somebody _does_ want it, we have not painted ourselves into a
corner).
> You can see what I decided to do in an evil merge in 'pu'.
>
> In short,
>
> * The short-and-sweet "-i" means both --regexp-ignore-case (grep) and
> --ignore-case (diff); and
>
> * The long-hand can be used to ask for case
> insensitive grep but case sensitive patch, or vice versa.
Yes, the evil merge looks sane, assuming both topics implement the
desired behavior.
I am a little dubious of the decision in jc/diff-ignore-case to have
"-i" imply "--ignore-case". For "git diff", it makes perfect sense. But
for "git log", it feels wrong. Ignoring case for the regexps is very
common, and ignoring case for the diffs is uncommon (it is, after all, a
feature we have gone many years without, and I don't remember anyone
bringing it up until recently).
As a user, I would be surprised that something common like "git log
--author=junio -i -p" would change diff generation between versions of
git. It's probably not a huge regression, as patches which actually
look different with --ignore-case are relatively rare, so you are
unlikely to see any difference if you trigger it accidentally. But that
just argues to me that it is a feature that one would want to turn on
explicitly, anyway.
-Peff
next prev parent reply other threads:[~2012-02-29 9:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 0:20 [PATCH v2 0/2] "log --regexp-ignore-case -S/-G<string>" Junio C Hamano
2012-02-29 0:20 ` [PATCH v2 1/2] grep: use static trans-case table Junio C Hamano
2012-02-29 8:28 ` Jeff King
2012-02-29 8:51 ` Junio C Hamano
2012-02-29 0:20 ` [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively Junio C Hamano
2012-02-29 8:35 ` Jeff King
2012-02-29 8:55 ` Junio C Hamano
2012-02-29 9:18 ` Jeff King [this message]
2012-02-29 11:40 ` Thomas Rast
2012-02-29 18:05 ` 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=20120229091855.GE14181@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).