On 10/10/2012 09:55 AM, Junio C Hamano wrote: > It took longer than expected, but here is a reroll of the previous > series to bring more recent "git grep" enhancements to the "--grep" > option of commands in "git log" family. > > The early part of the series (1-3) refactors the code that reads > configuration items related to "grep" and the code that mixes the > result with the command line options to prepare grep_opt, which so > far lived in builtin/grep.c, and moves them to the grep.[ch] at the > top-level. > > The middle part (4-6) reuses the code to set-up grep_opt refactored > by the earlier part of the series on revs->grep_filter that is used > in "git log --grep=..." processing. It incidentally fixes a small > bug where "git log -F -E --grep='<ere>'" did not look for matches to > the pattern in extended regular expression, and adds --basic-regexp > and --perl-regexp command line options to "git log" family for > completeness. > > The last one teaches "git log" family to honor the "grep.*" > configuration variables, e.g. "grep.patterntype", so that you can > say "git -c grep.patterntype=perl log --grep='(?:pcre)'". Maybe this has been discussed already, but it seems to me that adding a persistent setting that affects how "git log --grep" interprets the pattern argument could break some scripts that assume that the "old" interpretation is always used. Shouldn't this at least be documented as a backwards incompatibility? Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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