Re: Quickly searching for a note

Michael J Gruber [off-list ref] 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.

Junio C Hamano venit, vidit, dixit 22.09.2012 22:23:

Michael J Gruber [off-list ref] writes:

quoted

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.

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,
of course.

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.

Michael

On Sat, Sep 22, 2012 at 01:23:56PM -0700, Junio C Hamano wrote:

Michael J Gruber [off-list ref] writes:

quoted

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

On Sun, Sep 23, 2012 at 05:07:04PM +0200, Michael J Gruber wrote:

quoted

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

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,
of course.

I think Junio is going the other way than you think. That is, you still
run rev-list, but rather than call a sub-program, you call a snippet of
an embeddable script. Which is the same idea as yours, but theoretically
way faster.

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 ;)

Like this:

  git log --lua-filter='return subject().len > 100'

? :)

-Peff

Jeff King venit, vidit, dixit 25.09.2012 02:42:

On Sun, Sep 23, 2012 at 05:07:04PM +0200, Michael J Gruber wrote:

quoted

quoted

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

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,
of course.

I think Junio is going the other way than you think. That is, you still
run rev-list, but rather than call a sub-program, you call a snippet of
an embeddable script. Which is the same idea as yours, but theoretically
way faster.

quoted

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 ;)

Like this:

  git log --lua-filter='return subject().len > 100'

? :)

Like this! :)

Michael