Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:10

Jeff King [off-list ref] writes:
quoted
When given the "--regexp-ignore-case" (or "-i") option, which originally
was designed to affect case sensitivity of the search done in the commit
log part, e.g. "log --grep", the matches made with -S/-G pickaxe search is
done case insensitively now.
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").

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.

Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively

From: Jeff King <hidden>
Date: 2016-06-15 22:53:10

On Wed, Feb 29, 2012 at 12:55:35AM -0800, Junio C Hamano wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help