Jeff King <peff@xxxxxxxx> 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. -- 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