How do Git LFS and git-annex differ?
They do solve the same problem.
Let me start off with pro/con, then I'll move into technical differences.
git-annex
Pros:
- Supports multiple remotes that you can store the binaries.
- Can be used without support from hosting provider (for more details see here).
Cons:
- Windows support in beta, and has been for a long time
- Users need to learn separate commands for day-to-day work
- not supported by github and bitbucket
git-lfs
Pros:
- Supported by github, bitbucket and gitlab
- Most supported on all os's
- Easy to use.
- automated based on filters
Cons:
- Requires a custom server implementation to work. A simple ssh remote is not sufficient. Reference server is under development https://github.com/git-lfs/lfs-test-server.
Technical
git-annex
git-annex works by creating a symlink in your repo that gets committed. The actual data gets stored into a separate backend (S3, rsync, and MANY others). It is written in haskell. Since it uses symlinks, windows users are forced to use annex in a much different manner, which makes the learning curve higher.
git-lfs
Pointer files are written. A git-lfs api is used to write the BLOBs to lfs. A special LFS server is required due to this. Git lfs uses filters so you only have to set up lfs once, and again when you want to specify which types of files you want to push to lfs.
A major advantage of git annex is that you can choose which file you want to download.
You still know which files are available thanks to the symlinks.
For example suppose that you have a directory full of ISO files. You can list the files, then decide which one you want to download by typing: git annex get my_file.
Another advantage is that the files are not duplicated in your checkout. With LFS, lfs files are present as git objects both in .git/lfs/objects and in your working repository. So If you have 20 GB of LFS files, you need 40 GB on your disk. While with git annex, files are symlinked so in this case only 20 GB is required.