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.
If 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.
My 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".
Also 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.
Shallow 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.
Comments
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.
If 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.
Can I do that automatically so that only binaries are fetched shallow, and text is fetched deep? Otherwise it's not very useful.
My 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".
Also 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.
Shallow 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.