Re: How Blobs Work ( Blobs Vs. Deltas)

[Jakub Narebski <jnareb@gmail.com>]

"Feanil Patel" <feanil@gmail.com> writes:

> Hello,
> 
> I was reading about git objects in "The Git Community Book"
> (http://book.git-scm.com/1_the_git_object_model.html), which was
> posted on the mailing list a while back, and I was wondering something
> about blobs and how files are stored in any particular version.  If
> file A is changed from version one to version two there are two
> different blobs that exist for the two versions of the file, is that
> correct?  The Book was saying Git does not use delta storage so does
> this mean that there are two almost identical copies of the file with
> the difference being the change that was put in from version one to
> version two?

In Git there are two kinds of storage: loose objects and packs. Each
object generally starts as a loose object; for those it is like you
wrote: if you have two versions of some file, you would have both
of those contents of a file stored as separate objects (blobs).  Note
that those 'blob' objects are compressed, so they usually don't take
more time than current version of file and its backup.

But there exists also other type of storage, namely packed.  In the
past you had to pack (repack) objects by invoking "git repack" and
"git prune", and in more modern times by calling "git gc"; nowadays
this should be taken care of by git using "git gc --auto" behind.
When packing git tries to find objects which are close contents,
and store them as base object and binary delta (based on LibXDiff).
So you get benefits of delta storage, while on the API and script
level you always see single objects.

Note that explicit repacking allow git to not only consider versions
of the same file to diff against, tree and not only linear chains of
deltas (think branches), and while recency order is preferred it is
not enforced; objects and deltas are then compressed individually.

HTH
-- 
Jakub Narebski
Poland
ShadeHawk on #git