Question on git clone

Question on git clone

[Luben Tuikov]

Hi,

Any reason why "git clone" barfs, but cg-clone works without
a problem?

The message I get is this:

Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?

Thanks,
	Luben

Re: Question on git clone

[Junio C Hamano]

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.

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.

Re: Question on git clone

[Luben Tuikov]

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.
> 
> 
>