Re: Quickly searching for a note
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 22, 2012, 20:23 UTC
- Message-ID
- <7vk3vl3ixv.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <505DE30B.2000805@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 14 quoted lines
> 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.