Junio C Hamano venit, vidit, dixit 22.09.2012 22:23:
> Michael J Gruber <g...@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:
>> 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
>> 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,
Yes, the idea is "extend, don't embed" the other way round, so to say. I
still think extending "git log" so that it can call a script with commit
info already in the environment gives a more convenient approach then
"embedding git rev-list" into your own script. It's not more performant,
I just see many more requests of the type "grep notes" coming, i.e.
limitting based on other commit info, or in a different way then already
possible. Just image you want to find out who's responsible for those
commits in git.git with subject lengths > 100 ;)
The point is also that when you pipe rev-list into your script you have
to do all the output formatting yourself, or call "git log -1"/"git
show" again to have git do the output formatting after your script
decided about the limitting.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html