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/
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.