3 ms·
This seems like an odd problem, but I'm not as familiar with Git as I should be. Is there not a reasonable way to download only the most recent version of these
by nkurz 11y ago
This seems like an odd problem, but I'm not as familiar with Git as I should be. Is there not a reasonable way to download only the most recent version of these large binary files on the initial request, and then download the historical versions only in the (likely very rare) case that the user actually wants to use them? This would seem more useful in this case than hoping that binary diffs the repository small enough.
- adrusi 11y agoAlso not very well versed in git, but my understanding is that there is a way to clone a repo to only include latest revisions, but that this limits usage of git. I believe that fixing this was an area of active development a few months ago, its possible it already landed.
- gh02t 11y agoShallow clones are the term. It used to be that you couldn't pull remote changes or push local changes to/from a shallow clone, but that was fixed with v1.9 (early 2014). I'm not sure how LFS interacts with shallow clones though, as it's really a separate system that works in tandem with git more than a part of git itself.
- icebraining 11y agoIf you're talking about binary files merged into Git itself (not Git LFS, which is a separate mechanism), you can use "git clone --depth <n>" to get only the latest <n> revisions of the tree, and then use "git pull --unshallow" if you need to fetch the rest of the history.
- alkonaut 11y agoCan I do that automatically so that only binaries are fetched shallow, and text is fetched deep? Otherwise it's not very useful.
- icebraining 11y agoMy best guess would be to keep the binaries in a submodule, then after fully cloning the main repo, you would fetch the binaries with "git submodule update --init --depth 1".