Re: git-fetch pulls already-pulled objects?

[Junio C Hamano <gitster@pobox.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.