From: Shawn O. Pearce Date: Wed, 03 Jun 2009 19:52:05 GMT Subject: Re: [Patch] Prevent cloning over http from spewing Message-ID: <20090603195205.GN3355@spearce.org> In-Reply-To: <20090603194416.GA30333@coredump.intra.peff.net> Jeff King 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.