Re: [PATCH] Introduce a filter-path argument to git-daemon, for doing custom path transformations

["Johan Sørensen" <johan@johansorensen.com>]

On Wed, Mar 11, 2009 at 4:58 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Johan Sørensen schrieb:
>> This buys us a lot of flexibility when it comes to managing different
>> repositories, possibly located in many different dirs, but with a uniform
>> url-structure to the outside world.
>
> It's the first time that I see a deamon with this feature - except perhaps
> Apache's ModRewrite. Are you sure you are not working around your problem
> at the wrong place?
>
> Doesn't --interpolated-path already solve your problem? If not, then you
> at least you must describe in the documentation the use-cases when
> --path-filter should be preferred.

Maybe I am barking up the wrong tree, but here's my real-world use
case: I'm currently working on some bigger changes for gitorious.org,
where the repository url-structure could potentially change over time,
as a consequence of various features. Using the path-filter script I
can keep the old urls around and still working, and I can map any url
to a on-disk uniquely hashed path, so I don't have to move the files
around, maintain symlinks and so forth for information the gitorious
application already has nicely structured and easy to lookup.

I know these may be highly specialized needs, but so is
interpolated-path for the common user. I think this patch could be
useful for anyone else wanting to set up a flexible repo hosting
system. I think the url-structure is a major part of the UI for any
app exposing them, even for a git-daemon, so the mod_rewrite
comparison isn't too far fetched in my opinion...

> Your implementation does not pass the target hostname to the script, but
> it should; otherwise you lose flexibility (for virtual hosting).

Good point. I've added the hostname as well as the service name as
arguments for the script.

>> +     switch ((pid = fork())) {
[snip]
>
> Use start_command()/finish_command() instead of rolling your own fork/exec
> combo.

Ah nice! I'm sending an updated patch.


>
> -- Hannes
>

Cheers,
JS