Why do you say it's bad practice? Game assets come to mind, these aren't derived artifacts and you can't build the game without them.

This is one of the cases where git's inability to handle rewriting a public history is a pain. The art and programming departments should be able to develop along separate branches, and the programmers should be able to pull a tree from art that has everything between tags squashed (but in a reversible fashion in case there's a need to bisect something later).

Historically I've dealt with the problem by keeping code and assets in separate repositories (using different version control systems). While it's worthwhile to do so in order to use git for code it really is a pain.

To answer a couple of levels up, it's not bad practice because it isn't useful... there are many circumstances where having big binary blobs versioned and associated with code. It is bad practice because the tools are all written _for_ code and can get nasty when filled with binaries.

So there's a problem and a solution, but nobody seems to have put together the right magic yet.

It's only a bad practice because our tools don't support it properly.

There seems no reasonable argument that there is some predefined size limit that all assets in version control must, by natural law, fall under.

The criteria I have for version controlled assets is they must 1) be versionable, 2) have a comparison tool, and 3) be strongly connected to the other assets under control.

Yes, exactly.

It operates under a similar principle (committing hashes rather than file contents) but stores the actual file contents elsewhere rather than using a compression/deduplication within the repo itself.

It's neat, but it's more about replacing something like Dropbox than it is replacing git (despite being based on git). It also isn't particularly stable, though I have nothing but respect for the developer.

I backed Joey's kickstarter, but to my shame I have yet to give git-annex-assistant a spin.