git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Quickly searching for a note

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Sep 23, 2012, 15:07 UTC
Message-ID
<505F2598.7080704@drmicha.warpmail.net>
In-Reply-To
<7vk3vl3ixv.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 22.09.2012 22:23:
Show 30 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.
> 
> 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
Previous: Junio C HamanoNext: Jeff King
Message 14 of 19 in “Quickly searching for a note”
  1. Joshua JensenSep 21, 2012
  2. Andreas SchwabSep 21, 2012
  3. Joshua JensenSep 21, 2012
  4. Junio C HamanoSep 21, 2012
  5. Joshua JensenSep 21, 2012
  6. Junio C HamanoSep 21, 2012
  7. Joshua JensenSep 21, 2012
  8. Johannes SixtSep 21, 2012
  9. Joshua JensenSep 21, 2012
  10. Jeff KingSep 21, 2012
  11. Junio C HamanoSep 21, 2012
  12. Michael J GruberSep 22, 2012
  13. Junio C HamanoSep 22, 2012
  14. Michael J GruberSep 23, 2012
  15. Jeff KingSep 25, 2012
  16. Michael J GruberSep 25, 2012
  17. Jeff KingSep 25, 2012
  18. Junio C HamanoSep 25, 2012
  19. Junio C HamanoSep 22, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.