From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Sat, 22 Sep 2012 16:10:51 GMT
Subject: Re: Quickly searching for a note
Message-ID: <505DE30B.2000805@drmicha.warpmail.net>
In-Reply-To: <7v7grn3pfo.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 22.09.2012 01:51:
> Jeff King <peff@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
> 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.
> 

On my mental scratch pad (yeah, that's where the bald spots are) I have
the following more general idea to enhance the revision parser:

--limit-run=<script>::
--run=<script>:::
These options run the script `<script>` on each revision that is walked.
The script is run in an environment which has the variables
`GIT_<SPECIFIER>` exported, where `<SPECIFIER>` is any of the specifiers
for the `--format` option in the long format (the same as for 'git
for-each-ref').

In the case of `--limit-run`, the return code of `<script>` decides
whether the commit is processed further (i.e. shown using the format in
effect) or ignored.


So far the idea. We could also squash both the limitting and the
formatting option into one run option. Typical usecase could be

git log --limit-run='sh -c "test x$GIT_NOTE = xp@myid'

or the like. We could also feed <script> to a shell directly. We could
also make the limit option stop traversal (optionally). Just a scratch
pad, rwally ;)

Michael

P.S.: option name bike shedders: it's named after bisects's "run"; we
could name it after rebase-i's "exec" instead...