Jeff King <peff@xxxxxxxx> writes: > I think people have provided sane techniques for doing this with a > pipeline. But there is really no reason not to have --grep-notes, just > as we have --grep. It's simply that nobody has implemented it yet (and > nobody is working on it as far as I know). It would actually be a fairly > simple feature to add if somebody wanted to get their feet wet with git. I agree that the implementation will be simple once you figure out what the sensible semantics and external interfaces are. The latter is not that simple and certainly not something for newbies to solve on their own. That is why I didn't mention it. But now you brought it up, here are a few thinking-points as a starter: - Wouldn't it be more intuitive to just let the normal "--grep" to also hit what "--show-notes" would add to the output? Does it really add value to the end user experience to add a separate "--grep-notes=P4[0-9]*" option, even though it would give you more flexibility? Not having thought things through thorouly, I still answer this question both ways myself and what the right user experience should look like. - Do we want to be limited to one notes tree? Would it make sense to show notes from the usual commit notes but use different notes tree for the sole purpose of restricting visibility? If we wanted to allow that for people who want flexibility, but still want to use only one and the same by default, what should the command line options look like? - Would it be common to say "I want commits with _any_ notes from this notes tree"? Having to say "--grep-notes=." for such a simple task, if it is common, feels a bit clunky. -- 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