Hi, On Tue, 14 Apr 2009, Nicolas Pitre wrote: > On Tue, 14 Apr 2009, Johannes Schindelin wrote: > > > IMO the best we could do under these circumstances [unreliable > > network] is to use fsck --lost-found to find those commits which have > > a complete history (i.e. no "broken links") -- this probably needs to > > be implemented as a special mode of --lost-found -- and store them in > > a temporary to-be-removed namespace, say > > refs/heads/incomplete-refs/$number, which will be sent to the server > > when fetching the next time. (Might need some iterations to get > > everything, though.) > > Well, although this might seem a good idea, this would help only in > those cases where there is at least one complete revision available, > i.e. no delta needed. This is usually true for the top commit after a > repack which objects are all stored at the front of the pack and serve > as base objects for deltas from subsequent (older) commits. Thing is, > that first revision is likely to occupy a significant portion of the > whole pack, like no less than the size of the equivalent .tar.gz for the > content of that commit. To see what this represents, just try a shallow > clone with depth=1. For the Linux kernel, this is more than 80MB while > the whole repo is in the 200MB range. So if your connection isn't > reliable enough to transfer at least that amount then you're screwed > anyway. Good point. Sorry for not thinking it through, Dscho -- 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