Re: "git-send-pack"

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jul 1, 2005, 05:01 UTC
Message-ID: <Pine.LNX.4.21.0507010033080.30848-100000@iabervon.org>
In-Reply-To: <Pine.LNX.4.58.0506301655310.14331@ppc970.osdl.org>

On Thu, 30 Jun 2005, Linus Torvalds wrote:

Show 10 quoted lines

> 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*