On Sat, Sep 29, 2012 at 12:55 AM, Junio C Hamano <gits...@pobox.com> wrote:
> For that to happen, the code _must_ know what kind of headers we
> would support; discarding the existing enum is going in a wrong
> direction.

Or what kind of manipulation is required for a header. The caller can
decide if it wants such manipulation or not. Somebody might want to
grep committer's date, for example.

> When we introduce "git log --header=frotz:xyzzy" option that looks
> for a generic "frotz " header and tries to see if "xyzzy" textually
> appears in the field, we may want to add a generic "this is not a
> header that we have special treatment for" enum to the mix.  But for
> known kinds of headers, we would need a list of what each header is
> and what semantics it wants.
> So please reconsider undoing [1/3], and rerolling [2/3] that depends
> on it.

Done. The enum is kept. I added a few tests about grepping timestamp
in 1/3 to keep people (or myself) from making the same mistake I did.

3/3 is reposted for completeness, I don't care much about notes (so
far). It's up to you to take or drop it.

Nguyễn Thái Ngọc Duy (3):
  grep: prepare for new header field filter
  revision: add --grep-reflog to filter commits by reflog messages
  revision: make --grep search in notes too if shown

 Documentation/rev-list-options.txt |  8 ++++++++
 grep.c                             | 10 +++++++++-
 grep.h                             |  7 +++++--
 revision.c                         | 26 ++++++++++++++++++++++++--
 t/t7810-grep.sh                    | 38 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 84 insertions(+), 5 deletions(-)


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