Re: Quickly searching for a note
- From
Jeff King <peff@peff.net>
- Date
- Sep 25, 2012, 00:38 UTC
- Message-ID
- <20120925003855.GB19586@sigill.intra.peff.net>
- In-Reply-To
- <7vk3vl3ixv.fsf@alter.siamese.dyndns.org>
On Sat, Sep 22, 2012 at 01:23:56PM -0700, Junio C Hamano wrote:
Show 25 quoted lines
> 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.
Nor me. I experimented long ago with a perl pipeline that would parse commit messages and allow Turing-complete grepping. I recall it was noticeably slow. I cannot imagine what forking for each commit would be like.
Actually, wait, I can imagine it. Git has ~33K commits. Doing 'sh -c exit' takes on the order of .002s. That's a minute of processing to look at each commit in "git log", assuming the filtering itself takes 0 seconds.
> If we linked with an embeddable scripting language interpreter > (e.g. lua, tcl, guile, ...), it may be a more practical enhancement, > though.
Agreed. I just posted a patch series that gives you --pretty lua support, though I haven't convinced myself it's all that exciting yet. I think it would be nicer for grepping, where the conditionals read more like regular code. Something like:
git log --lua-filter='
return
author().name.match("Junio") &&
note("p4").match("1234567")
'reads OK to me.
-Peff