From: Luben Tuikov <luben_tuikov@adaptec.com>
Date: Thu, 06 Oct 2005 19:56:31 GMT
Subject: Re: Question on git clone
Message-ID: <4345816F.1080003@adaptec.com>
In-Reply-To: <7v64sbyk5e.fsf@assigned-by-dhcp.cox.net>

On 10/05/05 12:59, Junio C Hamano wrote:
> Luben Tuikov <luben_tuikov@adaptec.com> writes:
> 
> 
>>Cannot get remote repository information.
>>Perhaps git-update-server-info needs to be run there?
> 
> 
> Because HTTP support in git-fetch chooses not to trust the
> directory index the HTTP server may spit out, and relies solely
> on having info/refs file available there for discovering refs.
> 
> It is debatable if HTTP support in git-fetch should fall back on
> discovery using "wget -r" like Cogito does, when the info/refs
> file is not found.  I've written about this once on this list --
> I demonstrated what you would see if you do "wget -r" against
> git.git/refs/ on kernel.org; you will see why I do not think it
> is necessarily a better approach.

Thanks Junio for the reply.

I looked and indeed info/refs was ug+r while it should've been
a+r.  That fixed it.

Thanks again,
	Luben


> 
> Not doing refs discovery using directory index forces the owner
> of an HTTP reachable repository to create info/refs by running
> update-server-info.  This is a good thing -- it trains him to
> behave.
> 
> update-server-info does not just create info/refs. It also
> creates another file objects/info/packs, which is needed for
> fetching over a commit walker if the repository is packed.
> AFAIK, even if you are using Cogito, you would not succeed
> pulling from a repository that is packed and does not have this
> file.
> 
> There was a discussion about helping Cogito's tag-tracking.  The
> downloading side needs to know if any new tag available on the
> other side refers to a commit on the branches the downloader
> tracks, without pulling everything that tag object refers to
> first.  One way to help achieving this has been offered, which
> would involve adding a bit more information to info/refs, to say
> what object each tag refers to.  It could be done on the client
> side, but it is far simpler if this kind of help is given on the
> server side.
> 
> I anticipate in the future we may need to have more auxiliary
> files, or to add more information to existing auxiliary files,
> that summarize what the repository has for downloaders, and 
> code to do so would be added to update-server-info, so the
> repository owner needs to learn to run only one command.
> 
> 
>