From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 22 Sep 2012 20:23:56 GMT
Subject: Re: Quickly searching for a note
Message-ID: <7vk3vl3ixv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <505DE30B.2000805@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

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

You could argue that the above is not an inpractical solution as
long as the user of --run, which spawns a new process every time we
need to check if a commit is worth showing in the log/rev-list
stream, knows what she is doing and promises not to complain that it
is no more performant than an external script that reads from
rev-list output and does the equivalent filtering.

I personally am not very enthused.

If we linked with an embeddable scripting language interpreter
(e.g. lua, tcl, guile, ...), it may be a more practical enhancement,
though.