From: Junio C Hamano <gitster@pobox.com>
To: "Johan Sørensen" <johan@johansorensen.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH] Introduce a filter-path argument to git-daemon, for doing custom path transformations
Date: Sat, 14 Mar 2009 11:23:30 -0700 [thread overview]
Message-ID: <7vprgkarq5.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <9e0f31700903140739g26be7981lb0fa411cdd8029e6@mail.gmail.com> (Johan Sørensen's message of "Sat, 14 Mar 2009 15:39:24 +0100")
Johan Sørensen <johan@johansorensen.com> writes:
>> Do you run git-daemon from inetd, or standalone, by the way?
>
> Standalone.
>
>> I am wondering how well it would scale if you spawn an external "filter path"
>> script every time you get a request.
>
> A quick test of 250 consecutive requests with ls-remote to localhost
> (all without the --verbose flag), slowest run:
> - Baseline (no --filter-path agument): 3.39s
>
> $ cat filter.c
> #import "stdio.h"
> int main (int argc, char const *argv[]) {
> printf("%s", "/existing.git\0");
> return 0;
> }
> - 3.84s
>
> $ cat filter.rb
> #!/usr/bin/ruby
> print "/existing.git\0"
> - 4.76s
>
> So, obviously highly dependent on how long it takes the script to
> launch and how much work it does. And yes, neither of the above really
> does anything :) nor takes any increased cpu load into account
>
> Another approach is to keep the external script running and feed it on
> stdin, but that would involve a bit more micro-management of the
> external process. I will revisit that idea if I find out that's
> needed.
I actually was hoping (especially we have Dscho on Cc: list) that somebody
like you would start suggesting a "plug in" approach to load .so files,
which would lead to a easy-to-port dso support with the help from msysgit
folks we can use later in other parts of the system (e.g. customizable
filters used for diff textconv, clean/smudge, etc.)
>> (by the way, "filter path" sounds as if it checks and conditionally
>> denies access to, or something like that, which is not what you are using
>> it for. It is more about rewriting paths, a la mod_rewrite, and I think
>> the option is misnamed)
>
> Maybe --rewrite-script or --rewrite-command instead?
Perhaps.
next prev parent reply other threads:[~2009-03-14 18:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-11 15:17 [PATCH] Introduce a filter-path argument to git-daemon, for doing custom path transformations Johan Sørensen
2009-03-11 15:58 ` Johannes Sixt
2009-03-12 10:13 ` Johan Sørensen
2009-03-12 11:29 ` Johannes Schindelin
2009-03-12 15:48 ` Johan Sørensen
2009-03-12 16:50 ` Johannes Schindelin
2009-03-12 19:06 ` Johan Sørensen
2009-03-14 6:58 ` Junio C Hamano
2009-03-14 14:39 ` Johan Sørensen
2009-03-14 18:23 ` Junio C Hamano [this message]
2009-03-19 0:15 ` Johannes Schindelin
2009-03-19 13:02 ` Johan Sørensen
2009-03-20 22:27 ` Johannes Schindelin
2009-03-12 10:26 ` Johan Sørensen
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=7vprgkarq5.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=johan@johansorensen.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).