> Quoting Andy Parkins <andyparkins@xxxxxxxxx>: > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
