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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html