Support large repositories!

I do think there's some reason for improvement here, but I must admit: often
the large resources are not terribly coupled to code change (ex: texture
tweaking), and I really, really like the fact that the "log" and "diff"
operators are local and blazing fast for textual artifacts. In the idea
world I could have all my binary blobs, too, however....

I think some UI slickness could be of big help here. It would also be nice
for managing third-party code/dependencies. At the same time, I do imagine
that the right kind of simple script could fetch the resources needed, at
least a conveniently as a P4/SVN install, while not losing access to git's
advantages when manipulating textual artifacts.

That's so common that only perforce seem to handle large binaries well?

I am afraid what is actually common is to generate large binaries from source.

Why are you putting the bytecode in the repository if it's coupled to the changes in the C/C++ source it should be built at the same time as all your native code...

So far I've heard two reasons why git is slow on binaries:

1. git normally rescans the entire file during operations like "git diff".
For huge binaries, this gets expensive.

I wonder if git could use the file's mtime to determine whether to scan it for changes. Or does it already?

2. The git format still has some limitations with large files.

Those seem fixable. I wonder if anyone is working on this.

Perhaps though it's wrong to accept the "can't merge" outcome, particularly in the video game context. It's my understanding that video games almost always have someone in the "toolsmith" role. A toolsmith's job could include providing merge for binary formats where that seems like a meaningful operation.

A really simple example is image merge. Given three layered "source images" one the "original", one of which has an improved stone effect layer made by artist A, and one the newly agreed "bad guy logo" in the emboss layer from lead designer B, it ought to be possible to take the changes made by A and by B and merge them to produce a new image which has the nicer stone AND the new logo. This is a mechanical operation (load both images, keep the layers that changed in both, save) but it requires insight into the format of the data.

But even non-mechanical merges are useful. Maybe the two unrelated changes to the intro level can't be merged by a machine, but the level design tool could be tricked out with a feature that can load another level and show it as a copyable ghost on top of the first. That takes merge from a painful and lossy operation worth avoiding at any cost (svn locking) to a relatively mundane occurrence, possible whenever necessary but not to be encouraged.

I was not thinking of "diff-the-concept" but of "diff-the-tool".

You can design a tool that will pretend to handle both text and binaries the same way, but it will only pretend to. Inside the box you will actually find two different tools.