Re: GIT Performance question

From: Jeff King <peff@peff.net>
Date: Apr 17, 2010, 10:37 UTC
Message-ID: <20100417103748.GC23110@coredump.intra.peff.net>
In-Reply-To: <1271498149921-4917066.post@n2.nabble.com>

On Sat, Apr 17, 2010 at 01:55:49AM -0800, santos2010 wrote:

Show 8 quoted lines

> Our company is evaluating SCM solutions, one of our most important
> requirements is performance as we develop over 3 differents sites across the
> world.
> I read that GIT doesn't use deltas, it uses snapshots. My question is: how
> could GIT have high performance (most of the users say that) if for
> synchronization (pull/push command) with e.g. a shared repository GIT
> transfers all modified files (and references) instead of the respective
> deltas?

Short answer: Git does store and transfer deltas. It generally beats any other system in terms of repo size.

Longer answer:

Git separates the concept of the history graph and the actual storage mechanism. So conceptually the history is a directed graph of snapshots, each representing the whole tree. But there are two things that save space:

  1. Git addresses content by its sha1. So each snapshot may refer to a
     file by the sha1 of its content, meaning we only have to store that
     content once.

  2. Git packs "objects" (where each file's content is in a single
     object) into "packfiles", in which it aggressively deltas objects
     against each other, including objects which do not come from the
     same path in your tree.

Git will store "loose" objects when performing most operations, but will occasionally pack when the number of objects get too high. You can also initiate a full pack by running "git gc".

For transferring between repositories, git will figure out which parts of the history each side has, and will only send the objects that the other side needs. In addition, it will send them as a packfile using delta compression, including deltas against objects that are not being sent but that it knows the other side has.

-Peff