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@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
