Re: Git Large Object Support Proposal

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 19, 2009, 23:44 UTC
Message-ID: <7vzlfh5b7y.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <d411cc4a0903191618x503db946n62d3132eece69175@mail.gmail.com>

Scott Chacon <schacon@gmail.com> writes:

Show 7 quoted lines

> The point is that we don't keep this data as 'blob's - we don't try to
> compress them or add the header to them, they're too big and already
> compressed, it's a waste of time and often outside the memory
> tolerance of many systems. We keep only the stub in our db and stream
> the large media content directly to and from disk.  If we do a
> 'checkout' or something that would switch it out, we could store the
> data in '.git/media' or the equivalent until it's uploaded elsewhere.

Aha, that sounds like you can just maintain a set of out-of-tree symbolic links that you keep track of, and let other people (e.g. rsync) deal with the complexity of managing that side of the world.

And I think you can start experimenting it without any change to the core datastructures. In your single-page web site in which its sole html file embeds an mpeg movie, you keep track of these two things in git:

	porn-of-the-day.html
        porn-of-the-day.mpg -> ../media/6066f5ae75ec.mpg

and any time you want to feed a new movie, you update the symlink to a different one that lives outside the source-controlled tree, while arranging the link target to be updated out-of-band.