Re: [PATCH] RFC: git lazy clone proof-of-concept
- From
- Jan Hudec <bulb@ucw.cz>
- Date
- Feb 9, 2008, 21:20 UTC
- Message-ID
- <20080209212059.GB17147@efreet.light.src>
- In-Reply-To
- <20080208233856.GA31593@glandium.org>
On Sat, Feb 09, 2008 at 00:38:56 +0100, Mike Hommey wrote:
Show 25 quoted lines
> On Fri, Feb 08, 2008 at 11:14:40PM +0000, Johannes Schindelin wrote: > > On Fri, 8 Feb 2008, Mike Hommey wrote: > > > On Fri, Feb 08, 2008 at 10:34:55PM +0000, Johannes Schindelin wrote: > > > > On Fri, 8 Feb 2008, Mike Hommey wrote: > > > > > Also note that the http transport uses info/http-alternates for > > > > > http:// urls. By the way, it doesn't make much sense that only > > > > > http-fetch uses it. > > > > > > > > I think it does make sense: nobody else needs http-alternates. > > > > > > If you're setting an http-alternate, it means objects are missing in the > > > repo. If they are missing in the repo and are not in alternates, how can > > > any other command needing objects out there work on the repo ? > > > > The point is: if you have a bare repository on a server that uses > > alternates, that path stored in info/alternates is usable by git-daemon. > > But it is not usable by git-http-fetch, since that does not have a > > git-aware server side. So if you want to reuse the _same_ bare repository > > _with_ alternates for both git:// transport and http:// transport, you > > _need_ to _different_ alternates: one being a path on the server, and > > another being an http:// url for http-fetch. > > But nothing prevents you from only setting an http-alternate. Also not > http-fetch can deal fine with info/alternates if it contains relative > paths.
They still may not work because of whatever mapping of paths to URLs the http server does. Also relative paths in info/alternates don't actually work; or rather, they do, but /not recursively/ (the code seems fixable, just someone would have to make sure the proper base is always used).
-- Jan 'Bulb' Hudec <bulb@ucw.cz>