Re: [PATCH v2 0/7] Tying loose ends on grep-pcre
On 10/10/2012 06:52 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: 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? If somebody scripts around log with hardcoded query --grep=... strings, they can force a particular variant from such a command line at the same time. But as always, responsibility of doing so is on the person who writes such a script; log being a Porcelain, we value ease-of-use in interactive case more than cast-in-stone interface stability like we do for plumbing commands. And that is exactly why the series avoids changing the behaviour for the rev-list plumbing. OK, you've convinced me. Thanks. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
[PATCH v2 0/7] Tying loose ends on grep-pcre
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)'. Obviously, it is too late for this cycle and will not graduate to 'master' before the 1.8.0 final. Junio C Hamano (7): builtin/grep.c: make configuration callback more reusable grep: move the configuration parsing logic to grep.[ch] grep: move pattern-type bits support to top-level grep.[ch] revisions: initialize revs-grep_filter using grep_init() log --grep: use the same helper to set -E/-F options as git grep log --grep: accept --basic-regexp and --perl-regexp log: honor grep.* configuration Documentation/rev-list-options.txt | 10 +++ builtin/grep.c | 133 ++-- builtin/log.c | 8 +- grep.c | 177 + grep.h | 6 ++ revision.c | 14 ++- t/t4202-log.sh | 6 ++ 7 files changed, 225 insertions(+), 129 deletions(-) -- 1.8.0.rc1.76.g5a375e6 -- 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
Re: [PATCH v2 0/7] Tying loose ends on grep-pcre
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 mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
Re: [PATCH v2 0/7] Tying loose ends on grep-pcre
Michael Haggerty mhag...@alum.mit.edu writes: 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? If somebody scripts around log with hardcoded query --grep=... strings, they can force a particular variant from such a command line at the same time. But as always, responsibility of doing so is on the person who writes such a script; log being a Porcelain, we value ease-of-use in interactive case more than cast-in-stone interface stability like we do for plumbing commands. And that is exactly why the series avoids changing the behaviour for the rev-list plumbing. -- 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
