Re: "git-send-pack"

[Daniel Barkalow <barkalow@iabervon.org>]

On Thu, 30 Jun 2005, Linus Torvalds wrote:

> On Thu, 30 Jun 2005, Daniel Barkalow wrote:
> > 
> > I suspect that I'll be able to merge send-pack/receive-pack with
> > ssh-push/ssh-pull this evening, and then it'll have the feature of not
> > caring too much which side your command line is on.
> 
> The simple thing to do is to just get one commit at a time, see if you 
> have it already, parse if it not, and go on to the parents.
> 
> That would fit the current git-pull thing, and may be good enough, but it 
> has the downside that it can need a _lot_ of back-and-forth fecthing of 
> commit objects from the other side until you find the one you want. That's 
> going to be _very_ slow over a high-latency connection.
> 
> So what I'd suggest is:
> 
> 1- puller starts by just asking "what's your SHA1 for the ref I want"
> 
>    The puller wants to know this, because a common case may be that it 
>    already has it, in which case it doesn't need to do anything. But more 
>    importantly, the puller will need to know this anyway if it gets an 
>    object-pack, so that the puller can update it's FETCH_HEAD.

Already have this, for the non-pack case.

>  - At some point the server sees the first SHA1 it recognizes, and at that 
>    point the server will have to start working. It will just send back an 
>    "ok, got it" message (telling the client to not bother continuing to 
>    send it any more commit ID's), and then does
> 
> 	git-rev-list --objects ref-client-wants ^first-common-sha1 |
> 		git-pack-objects --stdout

Right.

>  - the client just unpacks the objects, and if successful, it puts the new 
>    top ref it got into FETCH_HEAD. It's now done.

Or wherever it's been told to, yes.

> And I do _not_ think that it makes a lot of sense to try to be symmetric.  
> For one thing, while a "git-send-pack" should update all the refs
> in-place, a "git-pull-pack" should _not_ update the ref, it should just
> set FETCH_HEAD instead and the puller can decide what he wants to do with
> that ref (possibly merge it, but possibly just make it be a new local
> branch "remote-branch").

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.

At least, this is how I've always done it; I've got a "linus" branch that
follows the public repo, and I commit changes to a different branch. I
suppose one could skip hanging onto this info, but it seems like an
obviously useful thing to keep, if for no other reason than that I want to
diff against it. This is essentially promoting FETCH_HEAD to a refs/heads/
thing, and having separate ones when you pull from separate sources.

I suppose things are different if you do a lot of one-shot pulls, rather
than tracking branches that you pull from; I'll need to think about this
case (assuming that's actually what you do).

	-Daniel
*This .sig left intentionally blank*