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 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.