Re: [Patch] Prevent cloning over http from spewing

["Shawn O. Pearce" <spearce@spearce.org>]

Jeff King <peff@peff.net> wrote:
> On Wed, Jun 03, 2009 at 12:32:06PM -0700, Shawn O. Pearce wrote:
> 
> > > That's clever, and I think an "object count" would be fine (after all,
> > > that is all that git:// fetching provides). However, I'm not sure how it
> > > would work in practice. When we follow a walk to a commit in a pack, do
> > > we really want to try to pull _just_ that commit?
> > 
> > No, we pull the whole pack.  So the progress meter would have to
> > switch to do a content-length thing for the pack pull, then go back
> > to the object queue.
> > [...]
> > By delaying trees/blobs, I meant delaying them for loose object
> > fetch only, not pack based fetch.
> 
> Ah, OK, I see. I wonder if that would make a big difference in practice.
> I expect repos to be fairly packed these days because of the I/O
> benefits (and even if people aren't doing it manually, we auto-gc
> working repos and keep pushed packs for publishing repos). So in
> practice by the time you got an accurate object count, you would be more
> or less done with the fetch (because you would have been grabbing the
> related blobs in packs as you grabbed commits and trees).

Good point, but not all repos are well packed.  Think of a repo that
gets pushed to a few times a day, always under 100 objects per push,
maybe Linus'.  Its a lot of loose stuff to fetch.

But, you probably are right that many of them are packed... and this
trick to try and get a more accurate progress display wouldn't be
worth the effort most of the time.  Likely not worth coding.

-- 
Shawn.