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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html