Git-lfs: Is `git lfs pull` still preferred over `git pull`?

Created on 31 Jan 2019 · 1Comment · Source: git-lfs/git-lfs

From the descriptions in https://github.com/git-lfs/git-lfs/issues/2594#issuecomment-330363293 it sounds like the smudging performance improvements git lfs pull brings are being upstreamed into git pull, which is awesome!

So if using Git 2.15.0 or above, is there still a reason to prefer git lfs pull to git pull, or is the plan to deprecate it as with git lfs clone?

Source

gibfahn

Most helpful comment

I think that we'll likely not deprecate the git lfs pull command, but for all intents and purposes, you should (likely) use git pull instead. Here's the difference:

git pull first gets new Git objects, then checks them out into your working copy, and _then_ invokes Git LFS to filter them during this process.
git lfs pull _scans_ your working copy and makes sure that LFS files that are supposed to be checked out have their corresponding large objects present in your local cache.

In practice, this means that git pull and git lfs pull behave similarly (and at similar speeds, as you note) with the caveat that git pull _will_ ask the remote for new objects, and git lfs pull will not.

ttaylorr on 1 Feb 2019

👍4

>All comments

I think that we'll likely not deprecate the git lfs pull command, but for all intents and purposes, you should (likely) use git pull instead. Here's the difference:

git pull first gets new Git objects, then checks them out into your working copy, and _then_ invokes Git LFS to filter them during this process.
git lfs pull _scans_ your working copy and makes sure that LFS files that are supposed to be checked out have their corresponding large objects present in your local cache.