Re: Quickly searching for a note

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 21, 2012, 23:51 UTC
Message-ID: <7v7grn3pfo.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120921233723.GA29433@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

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