On 8/7/07, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: > > I was on a crappy connection and it was frustrated seeing git-clone > > reached 80% then failed, then started over again. Can we support > > resumable git-clone at some level? I think we could split into several > > small packs, keep fetched ones, just get missing packs until we have > > all. > > This is uh, difficult over the native git protocol. The problem > is the native protocol negotiates what the client already has and > what it needs by comparing sets of commits. If the client says > "I have commit X" then the server assumes it has not only commit > X _but also every object reachable from it_. > > Now packfiles are organized to place commits at the front of the > packfile. So a truncated download will give the client a whole > host of commits, like maybe all of them, but none of the trees > or blobs associated with them as those come behind the commits. > Worse, the commits are sorted most recent to least recent. So if > the client claims he has the very first commit he received, that > is currently an assertion that he has the entire repository. I'm thinking about things like bisect and use it to cut the history into parts. Clients only use completed parts. Uncompleted parts are thrown away. So if users think they cannot suffer too big packs, they tell server to send smaller (and less efficient) packs. Anyway I don't have deep knowledge of Git internals, my opion could be completely wrong. -- Duy - 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
