Jeff King [off-list ref] writes:
Thanks to all other points.
quoted
* "git log -G" learned to pay attention to the "-i" option and can
find patch hunks that introduce or remove a string that matches the
given pattern ignoring the case.
This didn't parse well for me. Also, it affects -S, too, doesn't it?
Maybe:
* "git log -G" and "git log -S" learned to pay attention to the "-i"
option. When "-i" is given, their patterns will match
case-insensitively.
I was torn about this item, and indeed my earlier draft read like
yours but I removed "-S" as it felt it was more confusing than it
was worth. The thing is that -S does not take any pattern --- it is
meant to be given a (typically a multi-line) block of text to find
where the exact block cease to exist in the file.
* "git log -G" and "git log -S" learned to pay attention to the "-i"
option. With "-i", "log -G" finds patch hunks that introduce or
remove a string that matches the given pattern ignoring the case.
Similarly with "-i", "log -S" finds where the given block of text
appears or disappears from the file, but this comparison is done
case-insensitively.
On Wed, Mar 07, 2012 at 10:46:47PM -0800, Junio C Hamano wrote:
quoted
* "git log -G" and "git log -S" learned to pay attention to the "-i"
option. When "-i" is given, their patterns will match
case-insensitively.
I was torn about this item, and indeed my earlier draft read like
yours but I removed "-S" as it felt it was more confusing than it
was worth. The thing is that -S does not take any pattern --- it is
meant to be given a (typically a multi-line) block of text to find
where the exact block cease to exist in the file.
Yeah, though I think many people do treat it as a fixed-string pattern
(I typically use "git log -Sfoo" to search for "foo", though perhaps
that is because I trained my fingers long before "-G" existed. "-S" is
also a lot faster).
My initial reaction to your statement was "well, if we can't justify it
in the release notes, then perhaps it is wrong for -S to be respecting
-i". But I don't think that is right. The code is doing the right thing,
and it is merely that "-S" is a little-used and often-misunderstood
tool, and you would naturally want to avoid mentioning it to avoid
complicating the notes and confusing the reader.
* "git log -G" and "git log -S" learned to pay attention to the "-i"
option. With "-i", "log -G" finds patch hunks that introduce or
remove a string that matches the given pattern ignoring the case.
Similarly with "-i", "log -S" finds where the given block of text
appears or disappears from the file, but this comparison is done
case-insensitively.
I think that's much better.
Though as a minor nit, the thing I had trouble parsing originally was
"...that matches the given pattern ignoring the case". I think "...ignores
the case when finding patch hunks that introduce..." is a little easier
to read.
-Peff