{"thread":{"id":"2019","subject":"Question on git clone","startedAt":"2005-10-05T15:42:56Z","lastAt":"2005-10-06T19:56:31Z","messageCount":3,"participants":["Luben Tuikov","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"9704","messageId":"4343F480.30501@adaptec.com","threadId":"2019","inReplyTo":null,"subject":"Question on git clone","fromName":"Luben Tuikov","fromEmail":"luben_tuikov@adaptec.com","sentAt":"2005-10-05T15:42:56Z","receivedAt":"2005-10-05T15:42:56Z","isPatch":false,"sender":{"key":"luben_tuikov@adaptec.com","avatar":null},"body":"Hi,\n\nAny reason why \"git clone\" barfs, but cg-clone works without\na problem?\n\nThe message I get is this:\n\nCannot get remote repository information.\nPerhaps git-update-server-info needs to be run there?\n\nThanks,\n\tLuben\n"},{"id":"9716","messageId":"7v64sbyk5e.fsf@assigned-by-dhcp.cox.net","threadId":"2019","inReplyTo":"4343F480.30501@adaptec.com","subject":"Re: Question on git clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-05T16:59:41Z","receivedAt":"2005-10-05T16:59:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luben Tuikov writes:\n\n> Cannot get remote repository information.\n> Perhaps git-update-server-info needs to be run there?\n\nBecause HTTP support in git-fetch chooses not to trust the\ndirectory index the HTTP server may spit out, and relies solely\non having info/refs file available there for discovering refs.\n\nIt is debatable if HTTP support in git-fetch should fall back on\ndiscovery using \"wget -r\" like Cogito does, when the info/refs\nfile is not found. I've written about this once on this list --\nI demonstrated what you would see if you do \"wget -r\" against\ngit.git/refs/ on kernel.org; you will see why I do not think it\nis necessarily a better approach.\n\nNot doing refs discovery using directory index forces the owner\nof an HTTP reachable repository to create info/refs by running\nupdate-server-info. This is a good thing -- it trains him to\nbehave.\n\nupdate-server-info does not just create info/refs. It also\ncreates another file objects/info/packs, which is needed for\nfetching over a commit walker if the repository is packed.\nAFAIK, even if you are using Cogito, you would not succeed\npulling from a repository that is packed and does not have this\nfile.\n\nThere was a discussion about helping Cogito's tag-tracking. The\ndownloading side needs to know if any new tag available on the\nother side refers to a commit on the branches the downloader\ntracks, without pulling everything that tag object refers to\nfirst. One way to help achieving this has been offered, which\nwould involve adding a bit more information to info/refs, to say\nwhat object each tag refers to. It could be done on the client\nside, but it is far simpler if this kind of help is given on the\nserver side.\n\nI anticipate in the future we may need to have more auxiliary\nfiles, or to add more information to existing auxiliary files,\nthat summarize what the repository has for downloaders, and \ncode to do so would be added to update-server-info, so the\nrepository owner needs to learn to run only one command.\n"},{"id":"9772","messageId":"4345816F.1080003@adaptec.com","threadId":"2019","inReplyTo":"7v64sbyk5e.fsf@assigned-by-dhcp.cox.net","subject":"Re: Question on git clone","fromName":"Luben Tuikov","fromEmail":"luben_tuikov@adaptec.com","sentAt":"2005-10-06T19:56:31Z","receivedAt":"2005-10-06T19:56:31Z","isPatch":false,"sender":{"key":"luben_tuikov@adaptec.com","avatar":null},"body":"On 10/05/05 12:59, Junio C Hamano wrote:\n> Luben Tuikov writes:\n> \n> \n>>Cannot get remote repository information.\n>>Perhaps git-update-server-info needs to be run there?\n> \n> \n> Because HTTP support in git-fetch chooses not to trust the\n> directory index the HTTP server may spit out, and relies solely\n> on having info/refs file available there for discovering refs.\n> \n> It is debatable if HTTP support in git-fetch should fall back on\n> discovery using \"wget -r\" like Cogito does, when the info/refs\n> file is not found. I've written about this once on this list --\n> I demonstrated what you would see if you do \"wget -r\" against\n> git.git/refs/ on kernel.org; you will see why I do not think it\n> is necessarily a better approach.\n\nThanks Junio for the reply.\n\nI looked and indeed info/refs was ug+r while it should've been\na+r. That fixed it.\n\nThanks again,\n\tLuben\n\n\n> \n> Not doing refs discovery using directory index forces the owner\n> of an HTTP reachable repository to create info/refs by running\n> update-server-info. This is a good thing -- it trains him to\n> behave.\n> \n> update-server-info does not just create info/refs. It also\n> creates another file objects/info/packs, which is needed for\n> fetching over a commit walker if the repository is packed.\n> AFAIK, even if you are using Cogito, you would not succeed\n> pulling from a repository that is packed and does not have this\n> file.\n> \n> There was a discussion about helping Cogito's tag-tracking. The\n> downloading side needs to know if any new tag available on the\n> other side refers to a commit on the branches the downloader\n> tracks, without pulling everything that tag object refers to\n> first. One way to help achieving this has been offered, which\n> would involve adding a bit more information to info/refs, to say\n> what object each tag refers to. It could be done on the client\n> side, but it is far simpler if this kind of help is given on the\n> server side.\n> \n> I anticipate in the future we may need to have more auxiliary\n> files, or to add more information to existing auxiliary files,\n> that summarize what the repository has for downloaders, and \n> code to do so would be added to update-server-info, so the\n> repository owner needs to learn to run only one command.\n> \n> \n> \n"}]}