On Wed, Mar 07, 2012 at 10:46:47PM -0800, Junio C Hamano wrote: > > * "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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html