From: Daniel Barkalow Date: Fri, 01 Jul 2005 05:01:04 GMT Subject: Re: "git-send-pack" Message-ID: In-Reply-To: On Thu, 30 Jun 2005, Linus Torvalds wrote: > On Thu, 30 Jun 2005, Daniel Barkalow wrote: > > > > My expectation is that the puller will have a ref "remote-branch", and > > will therefore: (1) want to update it, and (2) know the last commit pulled > > from it. In this situation, we can skip figuring out the start (the two > > points I didn't quote), because we saved it from before. > > This is _never_ how I do things, so I think that's a bad expectation. I > have other peoples trees "just show up", since they are actually based on > mine.. Okay, so my next task will be to support this case. What I'm doing now is: - if the source is using an old version, fall back on individual objects - send one (or more) ids to exclude - find out if the server recognized any of the ids - if not, fall back on transferring individual objects (or we could try another batch) - request a pack for the given hash, excluding whatever we've said to exclude I've implemented this for the case of updating a head, and got it to transfer a pack of 11 objects. It took 31s (including connecting) to transfer the entire history of git (3973 objects) over a DSL-DSL link with a 39ms ping time. I sent the same thing with the old method previously, and it took ages (wasn't timing it, though). It should be possible to notice that we're not updating a ref, send all the refs you have instead, see if the source recognized any, try again with the next 70 commits, check, and repeat. Does this match what you were suggesting? I can send you the messy version tomorrow if you want to hack on it or test it, and I'll have a clean patch series over the weekend. -Daniel *This .sig left intentionally blank*