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 Haggerty
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to