Re: git-fetch pulls already-pulled objects?

2015-10-29 Thread Matt Glazar
l Message- From: Junio C Hamano Date: Thursday, October 29, 2015 at 11:42 AM To: Matt Glazer Cc: "git@vger.kernel.org" Subject: Re: git-fetch pulls already-pulled objects? >Matt Glazar writes: > >> Would negotiating the tree object hashes be possible on the client >

Re: git-fetch pulls already-pulled objects?

2015-10-29 Thread Junio C Hamano
Matt Glazar writes: > Would negotiating the tree object hashes be possible on the client without > server changes? Is the protocol that flexible? The protocol is strictly "find common ancestor in the commit history". Everything else is done on the sender. >>The object transfer is done by first

Re: git-fetch pulls already-pulled objects?

2015-10-29 Thread Matt Glazar
end. That makes sense (especially for 'git revert HEAD' situations). Thank you for your reply, Junio. -Original Message- From: Junio C Hamano Date: Thursday, October 29, 2015 at 10:32 AM To: Matt Glazer Cc: "git@vger.kernel.org" Subject: Re: git-fetch pulls already-

Re: git-fetch pulls already-pulled objects?

2015-10-29 Thread Junio C Hamano
Matt Glazar writes: > On a remote, I have two Git commit objects which point to the same tree > object (created with git commit-tree). What you are expecting _could_ be implemented by exchanging all tree and blob objects sending and receiving sides have and computing the set difference, but the

git-fetch pulls already-pulled objects?

2015-10-28 Thread Matt Glazar
On a remote, I have two Git commit objects which point to the same tree object (created with git commit-tree). If I fetch one of the commits, the commit object (including the tree object) is fetched. If I then fetch the other commit, the tree object (and its dependencies) is fetched *again* (I thin