[kirushik]

The problem with non-code assets in git is (or at least it was for us) not with such assets being large blobs with weird in-git storage model, but with such assets being _unmergeable_ in case of two parallel edits of the same object.

Since merges are not generally possible (except for some special usecases), one would expect version-control system's help in avoiding parallel edit situation at all. This is where svn's centralized server helps, allowing "pessimistic locking" of certain files and folders. AFAIK, Plastic also offers such a feature, when git cannot do anything like that by design.

[rmc]

> The problem with non-code assets in git is (or at least it was for us) not with such assets being large blobs with weird in-git storage model, but with such assets being _unmergeable_ in case of two parallel edits of the same object.

I tried storing large images in git once. And one problem was when git would try to do garbage collection every now and then. And start diffing all the images against each other to repack them to use less space. This was very CPU and memory intensive.

[ido]

git lfs was buggy/clunky for a while but it now seems to actually be pretty stable and usable.

We've been using it pretty much since it was integrated into github.