Jeff King <peff@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html