From: Daniel Barkalow Date: Thu, 30 Jun 2005 22:25:43 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: > > > > 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*