git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [Patch] Prevent cloning over http from spewing

From
Shawn O. Pearce <spearce@spearce.org>
Date
Jun 3, 2009, 19:15 UTC
Message-ID
<20090603191555.GL3355@spearce.org>
In-Reply-To
<20090603191050.GB29564@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
Show 14 quoted lines
> 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.
Show 6 quoted lines
>   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.
Previous: Jeff KingNext: Jeff King
Message 6 of 23 in “Prevent cloning over http from spewing”
  1. Prevent cloning over http from spewingsparse@infidigm.net, Jun 2, 2009
  2. Erik Faye-LundJun 3, 2009
  3. Jakub NarebskiJun 3, 2009
  4. Junio C HamanoJun 3, 2009
  5. Jeff KingJun 3, 2009
  6. Shawn O. PearceJun 3, 2009
  7. Jeff KingJun 3, 2009
  8. Shawn O. PearceJun 3, 2009
  9. Jeff KingJun 3, 2009
  10. Shawn O. PearceJun 3, 2009
  11. Tay Ray ChuanJun 4, 2009
  12. Jeff KingJun 4, 2009
  13. Tay Ray ChuanJun 7, 2009
  14. Tay Ray ChuanJun 7, 2009
  15. Jeff KingJun 8, 2009
  16. Tay Ray ChuanJun 10, 2009
  17. Tay Ray ChuanJun 10, 2009
  18. Jeff KingJun 11, 2009
  19. Tay Ray ChuanJun 22, 2009
  20. Tay Ray ChuanJul 20, 2009
  21. Jeff KingJun 8, 2009
  22. Tay Ray ChuanJun 7, 2009
  23. Jakub NarebskiJun 5, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.