From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
Joshua Jensen <jjensen@workspacewhiz.com>,
Johannes Sixt <j6t@kdbg.org>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Quickly searching for a note
Date: Sun, 23 Sep 2012 17:07:04 +0200 [thread overview]
Message-ID: <505F2598.7080704@drmicha.warpmail.net> (raw)
In-Reply-To: <7vk3vl3ixv.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 22.09.2012 22:23:
> 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
next prev parent reply other threads:[~2012-09-23 15:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-21 14:41 Quickly searching for a note Joshua Jensen
2012-09-21 15:10 ` Andreas Schwab
2012-09-21 18:34 ` Joshua Jensen
2012-09-21 17:21 ` Junio C Hamano
2012-09-21 18:29 ` Joshua Jensen
2012-09-21 20:04 ` Junio C Hamano
2012-09-21 20:25 ` Joshua Jensen
2012-09-21 20:50 ` Johannes Sixt
2012-09-21 21:10 ` Joshua Jensen
2012-09-21 23:37 ` Jeff King
2012-09-21 23:51 ` Junio C Hamano
2012-09-22 16:10 ` Michael J Gruber
2012-09-22 20:23 ` Junio C Hamano
2012-09-23 15:07 ` Michael J Gruber [this message]
2012-09-25 0:42 ` Jeff King
2012-09-25 7:24 ` Michael J Gruber
2012-09-25 0:38 ` Jeff King
2012-09-25 16:19 ` Junio C Hamano
2012-09-22 4:51 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=505F2598.7080704@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j6t@kdbg.org \
--cc=jjensen@workspacewhiz.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.