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

["Michael S. Tsirkin" <mst@dev.mellanox.co.il>]

> 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