2018-07-23 15:31 EDT, Terri Yu <[email protected]>: > I use Git LFS, because I have open source projects on GitHub and run > continuous integration testing on them. Git LFS is supported on GitHub and > the major continuous integration services (Travis, Appveyor). It seems to > be ok, except for having to pay for Git LFS bandwidth on GitHub when I'm > doing a lot of testing. Currently, I'm the only developer on my projects, > so I don't know how easy it would be for collaborators to use Git LFS. > Sometimes I have trouble with Git LFS not downloading the files when I > clone a Git repository and it is really annoying. >
Please be wary of Git-LFS on GitHub. Their pricing model is kind of twisted, and it is very possible that by using it, you are preventing people from forking it altogether (everything gets counted towards the upstream owners' quota, which might run out quickly). Also note that they charge for bandwidth, so you might lock your project for everyone if you reach your quota (or if someone in a fork makes you reach your quota). Until GitHub fixes their pricing <https://help.github.com/articles/about-storage-and-bandwidth-usage/>, it is a pretty terrible option for all but private projects. My own experience is that Git-LFS is a pretty good option (when used with anything but GitHub, e.g. GitLab), much faster than alternatives if you have to deal with a huge number of medium-sized files (ipfs, dat, dvc don't do very well in that situation). It integrates with diff and merge. However it does have some gotchas e.g. impossible to purge specific files from the local cache. It also doesn't have a good stand-alone open-source server implementation at the moment, which might matter to you. Cheers -- Rémi ------------------------------------------ The Carpentries: discuss Permalink: https://carpentries.topicbox.com/groups/discuss/Tb776978a905c0bf8-Mdfa6be610db0b6e0c8882c44 Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription
