Jeff King <p...@peff.net> 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
- 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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html