Re: [PATCH v2 0/7] Tying loose ends on grep-pcre
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Oct 10, 2012, 15:17 UTC
- Message-ID
- <5075919F.5030306@alum.mit.edu>
- In-Reply-To
- <1349855714-17008-1-git-send-email-gitster@pobox.com>
On 10/10/2012 09:55 AM, Junio C Hamano wrote:
Show 21 quoted lines
> 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@alum.mit.edu http://softwareswirl.blogspot.com/