Re: [PATCH] RFC: git lazy clone proof-of-concept

[Jan Hudec <bulb@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]

On Sat, Feb 09, 2008 at 00:38:56 +0100, Mike Hommey wrote:
> 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>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]