all our neuroimaging data collected at DBIC is placed under git-annex control (see for more pointers), etc. With those differences in mind, and that you need to pay for any adequate size allowance for git-lfs on github, I do not actually know yet anyone using git-lfs in my domain (neuroimaging), and I feel that user-base of git-annex is growing here. git-annex's approach with symbolic links to content works smoothly/efficiently and non-ambiguously in majority of the cases. git-annex version mode 6 is an attempt to go the same direction (primarily to work better on systems (Windows) with crippled filesystems (FAT)) but there are some shortcomings with this approach which would still need work at git level to make it work smoother. There is also a technical shortcoming: git-lfs AFAIK works via git smudge filters - so for big files it needs first to analyze their content first to even say if things have changed or not. It works for centralized solutions, such as github, but it limits its utility big ways: I cannot just manage data files among my own personal clones of a git repository, I cannot easily make use of public/institutional hosting to host my repositories with data (like we do on ), I cannot just "link" to data available online elsewhere - I would need to upload it first to the git-lfs server. AFAIK: git-lfs is more of a "one trick pony" solution - you need a git-lfs server where you host your data files and interact with it to upload/download. It doesn't limit you to a specific server - you could link or upload data to any other git clone of the repository (well, if there is also git-annex cmdline available on the other side, so can't be done for github), you could link to urls for files on the web, you could even "link" data files to the content of tar/zip-archives (that is what we do in datalad where public datasets come only in shape of those archives), you could upload your data files to "git-annex special remotes" anywhere with optional encryption etc. Behind the scene, git lfs would create a reference to your large file and does not store directly in the git repo.
#Git annex vs lfs install
But here you go: git-annex is more like a swiss-army knife for managing data within git. Init LFS git lfs install git lfs track 'largefilepattern' Then follow regular git workflow git add largefile git commit -m 'Init a very large file' git push origin HEAD. Git-annex vs git-lfs: my opinion might be biased, since I am one of the DataLad developers where we build on top of git-annex, and I have only superficial experience with git-lfs.
FAIR Data: great! if you have any recommendations or fixes, do not hesitate to contribute:
0 kommentar(er)
