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
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