I think the diff algo used for pack files was linked to one of the delta encoding out there: initially (2005) xdelta, and then libXDiff.
But then, as detailed below, it shifted to a custom implementation.
Anyway, as mentioned here:
Git does deltification only in packfiles.
But when you push via SSH git would generate a pack file with commits the other side doesn't
have, and those packs are thin packs, so they also have deltas... but the remote side then adds bases to those thin packs making them standalone.
(note: creating many packfiles, or retrieving information in huge packfile is costly, and explain why git doesn't handle well huge files or huge repo.
See more at "git with large files")
This thread also reminds us:
Actually packfiles and deltification (LibXDiff, not xdelta) was, from what I remember and understand, originally because of network bandwidth (which is much more costly than disk space), and I/O performance of using single mmapped file instead of very large number of loose objects.
LibXDiff is mentioned in this 2008 thread.
However, since then, the algo has evolved, probably in a custom one, as this 2011 thread illustrates, and as the header of diff-delta.c points out:
So, strictly speaking, the current code in Git doesn't bear any resemblance with the libxdiff code at all.
However the basic algorithm behind both implementations is the same.
Studying the libxdiff version is probably easier in order to gain an understanding of how this works.
/*
* diff-delta.c: generate a delta between two buffers
*
* This code was greatly inspired by parts of LibXDiff from Davide Libenzi
* http://www.xmailserver.org/xdiff-lib.html
*
* Rewritten for GIT by Nicolas Pitre <[email protected]>, (C) 2005-2007
*/
More on the packfiles the Git Book:
Git 2.18 adds to the delta description in this new documentation section, which now (Q2 2018) states:
Object types
Valid object types are:
OBJ_COMMIT (1)OBJ_TREE (2)OBJ_BLOB (3)OBJ_TAG (4)OBJ_OFS_DELTA (6)OBJ_REF_DELTA (7)
Type 5 is reserved for future expansion. Type 0 is invalid.
Deltified representation
Conceptually there are only four object types: commit, tree, tag and
blob.
However to save space, an object could be stored as a "delta" of
another "base" object.
These representations are assigned new types ofs-delta and ref-delta, which is only valid in a pack file.
Both ofs-delta and ref-delta store the "delta" to be applied to
another object (called 'base object') to reconstruct the object.
The difference between them is,
- ref-delta directly encodes 20-byte base object name.
- If the base object is in the same pack, ofs-delta encodes the offset of the base object in the pack instead.
The base object could also be deltified if it's in the same pack.
Ref-delta can also refer to an object outside the pack (i.e. the
so-called "thin pack"). When stored on disk however, the pack should
be self contained to avoid cyclic dependency.
The delta data is a sequence of instructions to reconstruct an object
from the base object.
If the base object is deltified, it must be converted to canonical form first. Each instruction appends more and more data to the target object until it's complete.
There are two supported instructions so far:
- one for copy a byte range from the source object and
- one for inserting new data embedded in the instruction itself.
Each instruction has variable length. Instruction type is determined
by the seventh bit of the first octet. The following diagrams follow
the convention in RFC 1951 (Deflate compressed data format).
