Re: Is anyone working on a next-gen Git protocol?

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Oct 11, 2012, 01:44 UTC
Message-ID: <CACsJy8DMStBNjucU2eitNdkYgk-1K04dxhqV2gpKOZkpLzR_iA@mail.gmail.com>
In-Reply-To: <7vlifeawd5.fsf@alter.siamese.dyndns.org>

On Thu, Oct 11, 2012 at 3:46 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> I've recently discovered that the current protocol can be amazingly
>> inefficient when it comes to transferring binary objects.  Assuming two
>> repositories that are in sync.  After a 'git checkout --orphan && git
>> commit', a subsequent transfers sends all the blobs attached to the new
>> commit, although the other side already has all the blobs.
>
> I do not think it has anything to do with binary, but what you
> deserve from using orphan, where you declared that the history does
> not have anything to do with the original.
>
> If both of your repositories had the two paralle lines of these
> histories as branches, the transfer would have went well with or
> without binary objects.

On the same inefficient subject, git does not try to share common objects for non-commit refs, for example tags pointing to trees. I have such a peculiar repo and if a new tag shares 90% the tree with existing tags, git-fetch to sends the whole tree of the new tag over the wire. It does not seem easy to fix though and is probably rare enough that does not justify proper support. As a work around, I generate commits that link all these tags/trees together in a predetermined order. Not nice but works ok.

-- 
Duy