[PATCH 0/6] Tying loose ends of extended "grep"

Over time we have added a few things to our "git grep" front-end, such as

 - grep.extendedregexp configuration (v1.7.5)
 - use of pcre (v1.7.6)
 - grep.patterntype configuration (v1.8.0)

But all the time, we forgot that "git log --grep" would need to honor them.

The first three patches should be uncontroversial. We move helpers out of builtin/grep.c to a more generic place, and fix a bug in the command line parser for "git log -F -E --grep='<ere>'" (this did not correctly enable regular expression).

The fourth patch adds "git log --perl-regexp --grep='<pcre>'".

The last two teaches "log --grep" to honor the same grep.* configuration variables.

color.grep and grep.linenumber should not matter, as the use of grep mechanism in "log --grep" is about boolean result "do we have hits?" and not about actually showing the hits in the output, but the users would expect that grep.extendedregexp and its more generalized version grep.patterntype are honored, which was not the case.

Junio C Hamano (6):
  grep: move configuration support to top-level grep.[ch]
  grep: move pattern-type bits support to top-level grep.[ch]
  log --grep: use the same helper to set -E/-F options as "git grep"
  log --grep: accept --basic-regexp and --perl-regexp
  log: pass rev_info to git_log_config()
  log --grep: honor grep.patterntype etc. configuration variables

 builtin/grep.c | 105 ++-------------------------------------------------------
 builtin/log.c  |  19 +++++------
 grep.c         |  99 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 grep.h         |   3 ++
 revision.c     |   8 +++--
 t/t4202-log.sh |   6 ++++
 6 files changed, 126 insertions(+), 114 deletions(-)