Nope - short answer - git internals store whole files even for the smallest change. The thinking is that "disk is cheap (compared to computing time)", and there are different algorithms to present diffs / history that's useful having the original files around.

At first glance, that seems like a bad idea, but peeking into the '.git' folder, there are certain advantages of it over diff/patch storage formats and vice versa.

Longer answers: https://stackoverflow.com/questions/41482898/git-seems-to-st...

I think Perforce does this too... it's not a problem as such, but since you can't silently rewrite history in Git it's somewhat hard to get rid of the old versions when they start taking up space. Perforce on the other hand lets you configure the history depth on a per-type or per-file basis. I think you can purge deleted files if you'd like, too? - you'd probably use this if you were keeping old builds in version control, or some other useful type of asset that's in principle possible to recreate.

This doesn't help in combination with its insistence on storing the entire repo locally - though it's possible Git LFS (which I haven't tried) would be able to help with this.

Lack of file locking is a genuine problem.

And I really don't think you can handwave away Git's terrible usability with a "besides"...

There are things like git lfs, but these feel like hackarounds rather than proper fixes to me. Github's tiny LFS quotas giving me frustration over ~100MB of lfs data don't help either, which I can't raise because I'm a random dude who lacks billing/admin permissions for PistonDevelopers: https://github.com/PistonDevelopers/VisualRust/issues/302

If git supported large files well you'd still have that problem; Github is just not interested in becoming an hosting provider for such files.

And while LFS is certainly a hack, being separate is actually an advantage here; PistonDevelopers could host their own LFS server while continuing to use Github for their development, whereas if it was integrated they would be forced to pay GH or move out.

That said, I prefer git-annex to LFS, since it doesn't need a custom server; you can just use a "dumb" file server (rsync, webdav, S3, etc), with all the metadata being synced over the git repo.

> Github is just not interested in becoming an hosting provider for such files.

That's a strange claim given that they authored git lfs in the first place and run servers for it.

> That said, I prefer git-annex to LFS, since it doesn't need a custom server; you can just use a "dumb" file server (rsync, webdav, S3, etc), with all the metadata being synced over the git repo.

Significantly better multi-remote support as well from what I can tell, which would make transitioning or partially transitioning significantly easier. OTOH, no filters so you'll be manually spamming `git annex get` as I understand it: http://git-annex.branchable.com/todo/smudge/

Also it didn’t have native file locking which makes it a no-go for any non-text often changing content. I’m not sure if this has been addressed, or whether some plugin has become the de-facto standard to solve this?

File locking basically being the antithesis to a distributed version control system, I can't really see how it would fit into Git. How would it work for a system with no central repository?

It might make more sense to implement this within the services that emulate a central repository on top of Git.

You lock it in one central repository. There is typically a blessed repository somewhere, at least in every single project I have seen.

I know of no one and no project that uses the bare git in a truly distributed sense that isn’t just one central repo with multiple users, or in rare cases a hierarchy of repos such as the Linux kernel.

This is also why the github/lab style services are so popular - it’s what people need. But I don’t think that’s a reason to keep this feature away from git itself. I don’t think many want to have to use github just to get this one feature, and as I said, for any repo hosting binary content (common) and using one or more central blessed repos (nearly universal) - it’s very hard to live without.

Gitolite has a fine implementation of locking in Git.

http://gitolite.com/gitolite/locking/#locking-binary-files

Locking is implemented centrally by gitolite. It would be nice if other services implemented the same mini-protocol.

Sketch files are zip archives containing a bunch of JSON, so they're likely looking at/storing extracted state.

Pretty much every modern version control system treats binary files as undiffable and simply stores the whole thing as a hunk. The issue with Git affects pretty much all distributed version control since it requires keeping the entire history locally, so binaries with lots of changes vastly bloats the local repository. Stuff like Git LFS exists to work around that, by storing binaries in a central location instead, but that of course means that your system is no longer really distributed...