From: Luben Tuikov <luben_tuikov@adaptec.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: Question on git clone
Date: Thu, 06 Oct 2005 15:56:31 -0400 [thread overview]
Message-ID: <4345816F.1080003@adaptec.com> (raw)
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.
>
>
>
prev parent reply other threads:[~2005-10-06 19:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-05 15:42 Question on git clone Luben Tuikov
2005-10-05 16:59 ` Junio C Hamano
2005-10-06 19:56 ` Luben Tuikov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4345816F.1080003@adaptec.com \
--to=luben_tuikov@adaptec.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.