Re: [PATCH] grep --no-index: allow use of "git grep" outside a git repository

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jan 17, 2010 at 10:30:19PM -0800, Junio C Hamano wrote:

> Jeff King <peff@xxxxxxxx> writes:
> 
> > Hmm. I like the new behavior. The implementation feels a little
> > hack-ish, like we should really be supporting full-on:
> >
> >   git log --author=me --and --grep=foo
> >
> > That gets a little weird, though. We already have "--not" for ref
> > limiting, so clearly there is some conflict ...
> 
> That is fundamentally wrong.
> 
> Remember, "grep" works on two levels: a line matches or does not match the
> given set of patterns (rather, the expression given), and matched lines
> are shown.  A file as a whole is considered to have matched if one or more
> lines produced a match, or under the --all-match option, only when all of
> the top-level ORed terms in the expression have fired for some lines in
> it.

Fundamentally wrong for the way "log --grep" is currently implemented
perhaps, but I don't see anything wrong with considering each commit as
a single "record", just as regular grep considers each line to be a
record. That is a much more useful distinction for log traversal than
lines, which are useless from the user's perspective. If searching for
two terms, I care about whether they are in the same commit message, but
I don't care at all about line breaks.

Yes, I know that internally --author is really about line-matching the
commit headers, but that is an implementation detail. The mental model
we should present to the user is record-matching based on specific
fields like author, committer, or body text.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]