Re: [3/4] What's not in 1.5.2 (new topics)

From: Michael S. Tsirkin <mst@dev.mellanox.co.il>
Date: May 18, 2007, 11:08 UTC
Message-ID: <20070518110804.GD4708@mellanox.co.il>
In-Reply-To: <200705181021.30062.andyparkins@gmail.com>

Show 20 quoted lines

> Quoting Andy Parkins <andyparkins@gmail.com>:
> Subject: Re: [3/4] What's not in 1.5.2 (new topics)
> 
> On Friday 2007 May 18, Josef Weidendorfer wrote:
> 
> > It all depends on how we construct the default URL out of the subproject
> > identifier. Options:
> > (1) do not try to construct a default URL at all. Error out without a
> > config (2) use a configurable rewriting scheme like s/(.*)/git://host/\1/
> > (3) automatically detect a senseful rewriting scheme
> >
> > Let's start with (1). We can invent convenient default schemes later on.
> 
> All good; except let's start with 
> 
>  (1) if no config, try using the key itself - error out if that fails
> 
> Then everybody is happy - if you want to use your system where the key is not 
> a URL, then don't - you'll get the error you want.  If the user chose to use 
> a URL then magic will happen.

I don't want an error. No one wants an error.

I want to be able to clone a super project, a subproject, and use my copy of both instead of the original - including cloning my copy, pulls between such clones, being able to verify that they are identical.

What I *don't* want is a situation where the fact that original repository resides in north america necessarily means that everyone who looks at *my* clone of it will do a round trip to north america too.

And this means that URLs must be out of tree, but does *not* mean that git-daemon should not serve them for user's convenience.

How about an ability for git-daemon to get commands with git-config?

-- 
MST