git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Martin Langhoff <martin.langhoff@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Status of dumb http transport?
Date: Sun, 30 Jan 2011 08:01:36 -0800 (PST)	[thread overview]
Message-ID: <m3pqre9y9y.fsf@localhost.localdomain> (raw)
In-Reply-To: <AANLkTik99NNjNwLbj3-xEvVqiYUENiaREYAeJUC0bwVY@mail.gmail.com>

Martin Langhoff <martin.langhoff@gmail.com> writes:

> What is the state of dumb http transport today, for fetching updates?
> Is the client code smart enough to fetch indexes and use range
> requests? If so, how does that fare for latency?

A good description of "dumb" http transport can be found in Pro Git
book, in chapter 9.6 "Transfer Protocols", section "The Dumb Protocol"
http://progit.org/book/ch9-6.html
 
In short "dumb" http transport is realy dumb, it consults
.git/info/refs to know where to start from, and
.git/objects/info/packs to know what packfiles are available (both are
generated by git-update-server-info, usually run from update hook).

Starting from appropriate object, it tries to download loose object,
if posible, and if not then it downloads index files to know which
packfile to download.  It walks the chain down checking which objects
it has, and if there is one missing it downloads it.  It always
downloads _whole_ pack files.  It doesn't use range request... what's
more, as far as I know it doesn't know how to resume partially
downloaded packfile (hough it wouldn't re-download packfile it already
got).

> Background: I am looking at whether yum repositories' data (currently
> in sqlite & xml) could benefit from being a git (or very gittish)
> database -- with a bit of re-organizing to make it git-efficient of
> course.
> 
> Not the data that would benefit, but rather, users pulling updates
> from fast-moving repos (updates, updates-testing, rawhide...).
> 
> One of the constraints is that this has to be http, and work well
> across a universe of mirrors (that won't install or configure
> software) and the good bad and ugly world of http proxies. Yum can be
> taught to use the git proto, but that won't gain widespread use
> quickly -- http is and will be the mainstay for a long time.

Note that from some time we have "smart" http protocol, which is
almost git protocol proxied over http... with addition that http
protocol is stateless.  Default git-http-backend CGI script falls back
to "dumb" protocol if client doesn't support smart http transport.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

  reply	other threads:[~2011-01-30 16:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-30 15:07 Status of dumb http transport? Martin Langhoff
2011-01-30 16:01 ` Jakub Narebski [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-01-30 14:57 Martin Langhoff

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=m3pqre9y9y.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=martin.langhoff@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).