Re: Question on git clone
- From
- Luben Tuikov <luben_tuikov@adaptec.com>
- Date
- Oct 6, 2005, 19:56 UTC
- 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:
Show 17 quoted lines
> 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
Show 31 quoted lines
> > 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. > > >