git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Question on git clone

From
LTLuben 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.
> 
> 
> 
Previous: Junio C Hamano
Message 3 of 3 in “Question on git clone”
  1. Luben TuikovOct 5, 2005
  2. Junio C HamanoOct 5, 2005
  3. Luben TuikovOct 6, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.