Mix of objects and pointers after cloning - prune -f not working about git-lfs HOT 1 OPEN

Hey, I'm sorry you're having trouble. You've posed a few questions, so I'll try to answer them, but not all in the original order.

Is there a way of cloning a LFS repo with only the pointers, and then at a later stage do git lfs checkout in order to get the large files?

Yes, you can use the GIT_LFS_SKIP_SMUDGE=1 environment variable to control whether the Git LFS client "smudges" when you clone (i.e., replaces pointer files with object contents). Then you can run git lfs checkout as needed.

How do i prune and clear the git objects?

I think what you may be noticing here, after running git lfs prune -f, is that files in your working tree which correspond to Git LFS pointer files in the repository still have the full Git LFS object contents, so you're seeing a * in the git lfs ls-files output. That's expected, because what git lfs prune manages is the Git LFS local cache under .git/lfs/objects, not the files in your working tree. I suspect that if you run find .git/lfs/objects -type f before and after git lfs prune you'll see the cached object files have been removed.

Note too in particular that .git/lfs/objects is distinct from .git/objects. The git lfs prune command only operates on the former, not the latter.

Why is the main that i pushed after migration only 1.2 gig, but the repo that i cloned is nearly 2 gig? The repo that i cloned have a mix of pointers and objects, whereas my latest push has only objects - which obviously should take more space?

To answer this fully I think we'd need to know how you're determining those sizes. A specific single Git LFS object in a repository may appear in either or both of your local working tree (if it's been "smudged" into place, to replace a raw pointer file) or your local Git LFS cache. If you don't want the files to be duplicated between the working tree and the cache, and your system supports it, the git lfs dedup command may help in this regard.

In addition, if you've previously run git lfs migrate import in the same working tree, any Git objects which were converted Git LFS objects may still exist in Git's various internal files, although they're not part of your Git history anymore. There was a recent issue, #5786, where the resolution was to instruct Git to prune all the now-unreachable objects after the Git LFS migration, to reduce the on-disk storage space. A fresh clone of the post-migration repository, though, should not have this issue.

You mention trying to prune the Git objects with git reflog expire and git gc. FWIW, I've found the command like the following can be helpful when trying to purge all unreachable Git objects (this is a simplified version from what's suggested in this StackOverflow question, as I didn't have any git rerere data):

$ git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.pruneExpire=now gc

Why am i getting a mix of pointers and objects after cloning main?
Shouldn't they all be objects (indicated with asterisks)?

I'm not certain what might be affecting your particular clone statement in this case. You might try running the clone with GIT_TRACE=1 GIT_TRANSFER_TRACE=1 GIT_CURL_VERBOSE=1 to get more information about which files are and aren't being smudged automatically.

from git-lfs.