Re: git for game development?

[Jeff King <peff@peff.net>]

On Tue, Aug 23, 2011 at 04:06:47PM -0700, Lawrence Brett wrote:

> I am very interested in using git for game development.  I will be working
> with a lot of binaries (textures, 3d assets, etc.) in addition to source
> files.  I'd like to be able to version these files, but I understand that
> big binaries aren't git's forte.  I've found several possible workarounds
> (git submodules, git-media, git-annex), but the one that seems most
> promising is bup.  I started a thread on the bup mailing list to ask about
> the best way to use bup with git for my purposes.  One of the respondents
> suggested forking git itself to include bup functionality, thereby extending
> git to handle binaries efficiently.
> 
> My question for this group is:  would there be interest in incorporating
> this sort of functionality into git core?  I would certainly find it
> compelling as a user, but have no idea how it would fit into the bigger
> picture.

Something bup-like in git-core might eventually be good. But IIRC, bup
introduces new object types, which mixes the abstract view of the data
format (i.e., commits, trees, and blobs indexed by sha1) with the
implementation details (e.g., now we have both loose objects in their
own files as well as delta-compressed objects in packfiles).

That means that bup-git clients and non-bup git clients don't interact
very well. Where non-bup is either a client that doesn't understand the
bup objects, or one that chooses not to use bup-like encoding for
particular blobs.

I don't remember all of the details of bup, but if it's possible to
implement something similar at a lower level (i.e., at the layer of
packfiles or object storage), then it can be a purely local thing, and
the compatibility issues can go away.

-Peff

PS I also agree with Junio's comment that we are not at the "planning a
solution" stage with big files, but rather at the "trying it and getting
experience on what works and what doesn't" stage.