Re: "git-send-pack"

On Thu, 30 Jun 2005, Linus Torvalds wrote:

On Thu, 30 Jun 2005, Daniel Barkalow wrote:

quoted

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*