3 ms·

git-lfs (and similar systems) split up the storage of objects into the regular git object store (for small files) and the large file storage. This allows you t

git-lfs (and similar systems) split up the storage of objects into the regular git object store (for small files) and the large file storage. This allows you to configure how you get and push large files independently of how you get and push regular objects. A shallow clone gives you some `n` commits of history (and the objects that they point to). Using LFS allows you to have some `m` commits worth of large files. If you want a completely distributed workflow, and have infinite local storage and infinite bandwidth, you can fetch all the large files when you do a normal `git fetch`. However, most people don't, so you can tweak this to get only parts of the local file history that you're interested in. Indeed this is a trade off that requires some centralization, but so does your proposed solution of a shallow clone. This adds some subtlety and configurability around that.

onionjake 11y ago
Yes, I just don't see why it couldn't have been done directly using/extending existing git protocols. The additional command and configuration (and perhaps object storage) would be needed either way.
- Coding_Cat 11y ago
  Perhaps by adding a .git_sections file which keeps track of different sets of files you might want to checkout, but don't need to. You could have it that you could define different targets (and a default) such that say you are working on a large video-game you could have one repository for everything, but define a "artists" "programmers" and "full" target, where artists can keep their huge assets together with the rest of the repo and programmers can do shallow pulls, not constantly fetching asset files which may or may not be necessary for what they're working on.
  - ethomson 11y ago
    It's not about checking out, though. git-lfs aims to avoid the unnecessary transfer and storage of large files. If you didn't want large files in the work tree, you would use sparse checkout. These are orthogonal problems.

onionjake 11y ago

Yes, I just don't see why it couldn't have been done directly using/extending existing git protocols. The additional command and configuration (and perhaps object storage) would be needed either way.

Coding_Cat 11y ago
Perhaps by adding a .git_sections file which keeps track of different sets of files you might want to checkout, but don't need to. You could have it that you could define different targets (and a default) such that say you are working on a large video-game you could have one repository for everything, but define a "artists" "programmers" and "full" target, where artists can keep their huge assets together with the rest of the repo and programmers can do shallow pulls, not constantly fetching asset files which may or may not be necessary for what they're working on.
- ethomson 11y ago
  It's not about checking out, though. git-lfs aims to avoid the unnecessary transfer and storage of large files. If you didn't want large files in the work tree, you would use sparse checkout. These are orthogonal problems.