For instance, if you need a single file/directory from another project in your repository.
For instance, if you need a single file/directory from another project in your repository.
Basically sparse checkout only populates the tree for the dependencies we want, and then git-lfs will only download the binaries that are present in the current worktree.
Works out pretty well.
Keep in mind though that sparse checkout still has the entire repository loaded in the `.git` object store, it just doesn't expose it in the worktree.
> This combination speeds up the data transfer process since you don’t need every reachable Git object, and instead, can download only those you need to populate your cone of the working directory
If you're only downloading what you need to populate the working directory how is it that `.git` will have the entire repository?
Edit:
wrowclif@wrowclif-desktop:~/Taccs2/p5_deps$ git grep "def returnValue"
twisted/install_linux_gcc54/lib/python2.7/site-packages/twisted/internet/defer.py:1350:def returnValue(val):
twisted/install_linux_gcc54/lib/python2.7/site-packages/twisted/internet/test/test_win32events.py:66: def returnValueOccurred(self):
twisted/install_win64_vc141/lib/python2.7/site-packages/twisted/internet/defer.py:1350:def returnValue(val):
twisted/install_win64_vc141/lib/python2.7/site-packages/twisted/internet/test/test_win32events.py:66: def returnValueOccurred(self):
twisted/vendor_base/src/twisted/internet/defer.py:1350:def returnValue(val):
twisted/vendor_base/src/twisted/internet/test/test_win32events.py:66: def returnValueOccurred(self):
wrowclif@wrowclif-desktop:~/Taccs2/p5_deps$ ls ./twisted/
install_linux_gcc54We are using sparse checkout. Partial clone is the one that only pulls down objects that are needed by the store.
Git’s partial clone is a more natural way of achieving the same outcome.
The last time this happened to me, I took it as a hint that I had split the repositories along the wrong lines. The repos should probably be either merged or divided further to prevent this.
1. Check the files hash themselves: while you can definitely put the commit ID in the URL, nothing prevents the remote server (though unlikely if github) to answer with another version of the file (and could even do so selectively for your build server).
2. Simple upgrade path: with submodules, you can just `cd` into them and run `git pull` or `git checkout v11.5.2`, and git itself could inform you that a newer version is available if tracking a branch.
I also agree with the contribution aspect, though it is less important in some cases.
I take the latest example I have in mind where this could have been useful: For integration into F-Droid, RiotX needed not to include binary artifacts of a library, but the source itself. The source repository is quite big (multiple languages), but the thing of interest is a single java file [1]. They ended up simply copy-pasting the file [2] in their repo, which makes its origin less obvious, and more subject to bit-rot and vulnerabilities.
[1]: https://github.com/google/diff-match-patch/blob/master/java/...