From the README:<p>> <i>Why not Git/Git-LFS, libgit2, or SVN?</i><p>> <i>Disadvantages:</i><p>> <i>(Without Git-LFS): Heavy cost with zipping, packing, and delta-compression for larger files</i><p>Given the caveat (without Git-LFS) it seems odd to include this in the list<p>> <i>If not properly tracked, binaries become accidentally part of "base" history</i><p>That's a big "if", and not an inherent problem. This could easily be resolved by any good design-focused UI (e.g. SnowTrack), so this seems a poor argument against using Git as a backend.<p>> <i>Removing older commits is cumbersome due to Gits commit hashing integrity</i><p>This (like the first bullet point) does not apply to Git-LFS.<p>> <i>Complicated rewriting history procedure</i><p>What?<p>> <i>Issues with binaries >4GB on Windows</i><p>A known bug in Git-LFS that they're working to fix. There are workarounds provided in the linked tickets (that could be leveraged by a UI / abstraction layer like SnowTrack).<p>This is the first item in the bullet list that is a real disadvantage of Git LFS, but the workaround for it seems much less effort than developing a new VCS backend from scratch.<p>> <i>Slow in binary modification detection</i><p>I'm not sure if this applies to Git or Git LFS; there's little detail provided. But if it's significant, this is probably the only really compelling disadvantage listed.<p>> <i>Git uses a restrictive license</i><p>And finally we see the real reason for not using Git.<p>---<p>NOTE: I don't mean to make out that building an alternative VCS to Git is not worth pursuing. Nor that it needs any specific justification. Just that listing a justification that seems (to me) mostly disingenuous is worth pointing out.