Re: [Patch] Prevent cloning over http from spewing
- From
Jeff King <peff@peff.net>
- Date
- Jun 11, 2009, 11:11 UTC
- Message-ID
- <20090611111141.GB4409@coredump.intra.peff.net>
- In-Reply-To
- <be6fef0d0906100703j57d109d5mb38e41330caa089b@mail.gmail.com>
On Wed, Jun 10, 2009 at 10:03:10PM +0800, Tay Ray Chuan wrote:
Show 5 quoted lines
> > My first complaint is that it is way too long. It wrapped in my > > 80-column terminal, causing all sorts of visual confusion. > > The byte counts can really take up alot of space. Perhaps we should > just show the size (MiB) and completed percentage, sans byte counts?
I think that makes sense. Especially because the (X/Y) in git's progress output usually refers to the number of _objects_, and there is nothing in the output to indicate that it is actually a byte count here.
I think it will need some tweaking of the progress code to show the percentage but not the actual byte counts, but it should be a relatively simple change.
> Fetching of objects and packs take place separately; it doesn't mean > that when '0' objects are being fetched, we're definitely fetching > something else (eg. packs). Perhaps we should "hide" the "Fetching 0 > objects" part when the number of simultaneous object fetches is 0?
Yes, though I really wonder if the "fetching" number is all that useful even when it is not zero. The _most_ important thing is to show the user that something is happening, and we are waiting on the network. And I think we largely show that through the "total bytes sent" and throughput counters.
Second to that is trying to give a sense of when the task may finish. But as we've discussed, we don't have a sense of the total number of objects until we actually fetch them. Showing progress within packs, and the total number of packs is somewhat useful there (though it can be misleading -- most of the time will probably be spent on one or two of the packs).
Show 6 quoted lines
> The total number of objects (320) increases as we "walk" the commits; > sometimes we need to fetch the "walked" objects, sometimes we don't > (eg. in packs we've fetched already). There's no way to know in > advance the total; hence, the continually updating of the total. I > don't think there's it's a problem; the idea is to let the user be > sure that git is active.
Right. But I think we are better off showing simple increasing numbers (like bytes or objects transferred) than misleading or inaccurate guesses of totals. The latter creates more frustration, I think.
Show 15 quoted lines
> > I wonder if you should start a newline every time we get to a new > > "phase". So you might see: > > > > Downloading %d loose objects: Z% (X/Y), x MiB | y KiB/s, done > > Fetching pack 1 of 2: Z% (X/Y), x MiB | y KiB/s, done > > Verifying pack 1 of 2: Z% (X/Y) > > Fetching pack 2 of 2: Z% (X/Y), x MiB | y KiB/s, done > > Verifying pack 2 of 2: Z% (X/Y) > > > > That assumes we download packs one at a time (is that right?). It does take > > a couple of lines to show what is going on, but I think most repos are > > only going to have a couple of packs (though in theory, you could have > > more "loose objects" lines interspersed with your packs). > > Yeah, we do download packs one at a time (as I said above).
But from what you wrote elsewhere in the message, it sounds like we may be downloading a pack _and_ a loose object at the same time. So my suggestion doesn't quite work in that case.
> the linux-2.6 repo has only 1 pack (and no http-alternates), so this > is weird.
Maybe we are fetching from different places:
$ wget 2>/dev/null -O - \ http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/info/packs P pack-ab6a95cfd1919f6e820a8b2670403292838cfc17.pack P pack-ff5d2e76c6b3d4c0a5a11efd36af43934c3744df.pack P pack-588543ec42616a86eef47bb53dd04cd8a864d9b5.pack P pack-93b35ef7e596e6839c020e36edfaf8206b0f78c4.pack P pack-c89a5bf3b095d812bf1068cd1c84f8a07c3403c5.pack P pack-2cc5038b758e40a40a4590b37a8019d1ba5a65a9.pack P pack-9f36ce46120d8d9ee32e6394bb5857d7e548826b.pack P pack-8bebad1b754473489d516549632e904c0b3178a2.pack P pack-6554949d36a94e012da6ca6134ef62ce347b2efa.pack
-Peff