Re: git-fetch pulls already-pulled objects?

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 29, 2015, 17:32 UTC
Message-ID: <xmqqd1vxshrd.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <D256A718.1373A%strager@fb.com>

Matt Glazar <strager@fb.com> 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 sender and the receiver do not exchange such a huge list.

The object transfer is done by first finding the common ancestor of histories of the sending and the receiving sides, which allows the sender to enumerate commits that the sender has but the receiver doesn't. From there, all objects [*1*] that are referenced by these commits that need to be sent.

[Footnote]

*1* There is an optimization to exclude the trees and blobs that can be cheaply proven to exist on the receiving end. If the receiving end has a commit that the sending end does *not* have, and that commit happens to record a tree the sending end needs to send, however, the sending end cannot prove that the tree does not have to be sent without first fetching that commit from the receiving end, which fails "can be cheaply proven to exist" test.