git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Jakub Narebski <jnareb@gmail.com>,
	sparse@infidigm.net, git@vger.kernel.org
Subject: Re: [Patch] Prevent cloning over http from spewing
Date: Wed, 3 Jun 2009 12:15:55 -0700	[thread overview]
Message-ID: <20090603191555.GL3355@spearce.org> (raw)
In-Reply-To: <20090603191050.GB29564@coredump.intra.peff.net>

Jeff King <peff@peff.net> wrote:
> On Wed, Jun 03, 2009 at 11:28:40AM -0700, Junio C Hamano wrote:
> > This is a toy patch; it hiccups for too long while getting each pack, and
> > it does not cleanly restore the display after it finishes, but I'll leave
> > it to interested readers as an exercise to properly do this using the
> > progress API.
> 
> This is much better, and I had roughly the same thought when I saw the
> original "stop http from spewing" patch. The output is confusing, but we
> need _some_ progress indicator.
> 
> Unfortunately, I don't think it's possible to give a "percent complete"
> because we are fetching as we walk, meaning we don't know where the end
> is until we get there (but I might be wrong, as I have never looked too
> closely at the http fetch code).

No, you are right Peff, you can't give a "percent complete" because
you don't know how much you need to fetch.

What we could do is try to organize the fetch queue by object type,
get all commits, then all trees, then blobs.  The blobs are the
bulk of the data, and by the time we hit them, we should be able
to give some estimate on progress because we have all of the ones
we need to fetch in our fetch queue.  But its only a "object count"
sort of thing, not a byte count.

When fetching a .idx or a .pack though, we should be able to show
progress... assuming the server sent us a Content-Length header.
If not, in the case of a pack, we could still show receive speed
like index-pack does.
 
>   1. summarize what we have fetched (N packs, N loose objects)
>   2. show what we are currently fetching (object or pack)
>   3. show the number of bytes retrieved for the current item
>   4. if the server provides content-length, show the percentage
>      completed for this object
>   5. show the current throughput

Yea.  My idea of sorting by type is also a lot more work... and
probably doesn't buy us any better output than what you just said.
:-)
 
-- 
Shawn.

  reply	other threads:[~2009-06-03 19:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-02 17:42 [Patch] Prevent cloning over http from spewing sparse
2009-06-03 10:21 ` Erik Faye-Lund
2009-06-03 10:39 ` Jakub Narebski
2009-06-03 18:28   ` Junio C Hamano
2009-06-03 19:10     ` Jeff King
2009-06-03 19:15       ` Shawn O. Pearce [this message]
2009-06-03 19:24         ` Jeff King
2009-06-03 19:32           ` Shawn O. Pearce
2009-06-03 19:44             ` Jeff King
2009-06-03 19:52               ` Shawn O. Pearce
2009-06-04 12:45         ` Tay Ray Chuan
2009-06-04 16:01           ` Jeff King
2009-06-07 10:31             ` Tay Ray Chuan
2009-06-07 11:21               ` Tay Ray Chuan
2009-06-08 12:24                 ` Jeff King
2009-06-10 14:03                   ` Tay Ray Chuan
2009-06-10 14:07                     ` Tay Ray Chuan
2009-06-11 11:11                     ` Jeff King
2009-06-22 12:10                       ` Tay Ray Chuan
2009-07-20 15:24                         ` Tay Ray Chuan
2009-06-08 11:54               ` Jeff King
2009-06-07 11:25           ` Tay Ray Chuan
2009-06-05  0:17     ` Jakub Narebski

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090603191555.GL3355@spearce.org \
    --to=spearce@spearce.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=peff@peff.net \
    --cc=sparse@infidigm.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).