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

From: Steffen Prohaska <prohaska@zib.de>
Date: Oct 10, 2012, 19:13 UTC
Message-ID: <035A66D9-FAF0-48EE-B161-7D0CAD92F2FB@zib.de>
In-Reply-To: <7vtxu5lyjr.fsf@alter.siamese.dyndns.org>

On Oct 8, 2012, at 6:27 PM, Junio C Hamano wrote:

> Once we go into "want/have" phase, I do not think there is a need
> for fundamental change in the protocol (by this, I am not counting a
> change to send "have"s sparsely and possibly backtracking to bisect
> history, etc. as "fundamental").

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.

This behavior is especially annoying when (mis)using git to store binary files. I was thinking for a while that it might be a reasonable idea to store binary files in a submodule and frequently cut the history in order to save space. The history would have little value anyway, since diff and merge don't make much sense with binary files.

Eventually, I abandoned the idea due to the current behavior of the protocol. I had expected that git would be smarter and behave more like rsync, for example, by skipping big blobs as soon as it recognizes that they are already available at both sides.

Maybe the new protocol could include an optimization for the described case. I don't know whether this would be a fundamental change.

    Steffen