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