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). -Peff -- 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