GIT-LFS-PULL(1)

πŸ’… GIT-LFS-PULL(1) β€” the manual page, bestie edition πŸŽ€

okay so real quick: this is git-lfs-pull, straight out of the git-lfs(1) suite. she's the one who grabs ALL your Git LFS files for the ref you're on, and yes she's iconic for it. let's get into it ✨


✨ NAME ✨

git-lfs-pull β€” downloads every single Git LFS file for the current ref & checks it out. that's the whole vibe. no cap. 🫢

πŸ¦‹ SYNOPSIS πŸ¦‹

git lfs pull [options] [<remote>]

🌸 DESCRIPTION 🌸

so what she does is: download the Git LFS objects for the ref you currently have checked out, and then update your working copy with the downloaded content if required. lowkey that's it, but she does it flawlessly. πŸ’…

she's generally equivalent to running these two commands, like, back to back:

$ git lfs fetch [options] [<remote>]
$ git lfs checkout

so if you've ever run those two in a row and felt powerful β€” yeah, that's her. main character energy. πŸ‘‘

okay now here's the part where you have to actually pay attention, bestie, because this is where behaviour depends on your Git version:

If the installed Git version is at least 2.42.0, then in a non-bare repository this command will, by default, fetch and check out Git LFS objects for files only if:

  • they are present in the Git index, and
  • they match a Git LFS filter attribute from a .gitattributes file that is present in either the index or the current working tree

(or β€” and this one's always true, no version check, no drama β€” if they match a Git LFS filter attribute in a local gitattributes file such as $GIT_DIR/info/attributes).

🫢 these constraints do not apply with prior versions of Git. older Git just does the thing. slay for her honestly.

In a repository with a partial clone or sparse checkout, it is therefore advisable to check out all .gitattributes files from HEAD before using this command, if Git v2.42.0 or later is installed. like, do it first, it's giving self-care. πŸ§–

Alternatively, the GIT_ATTR_SOURCE environment variable may be set to HEAD, which will cause Git to only read attributes from .gitattributes files in HEAD and ignore those in the index or working tree. pick your fighter. πŸ’€


In a bare repository, if the installed Git version is at least 2.42.0, this command will by default fetch Git LFS objects for files only if:

  • they are present in the Git index, and
  • they match a Git LFS filter attribute from a local gitattributes file such as $GIT_DIR/info/attributes

and the rules for bare repos get even stricter, so buckle up buttercup:

  • any .gitattributes files in HEAD will be ignored, unless the GIT_ATTR_SOURCE environment variable is set to HEAD
  • any .gitattributes files in the index or current working tree will always be ignored
😭 again: these constraints do not apply with prior versions of Git. older Git said "rules? never met her."

πŸ’œ OPTIONS πŸ’œ

  • -I <paths>, --include= <paths> β€” specify lfs.fetchinclude just for this one invocation; peep INCLUDE AND EXCLUDE below for the full tea πŸ“
  • -X <paths>, --exclude= <paths> β€” specify lfs.fetchexclude just for this one invocation; also see INCLUDE AND EXCLUDE πŸ“

🌈 INCLUDE AND EXCLUDE 🌈

you can configure Git LFS to only fetch objects that satisfy references in certain paths of the repo, and/or to exclude certain paths of the repo β€” which reduces the time you spend downloading stuff you literally do not use. it's giving efficiency. ⚑

In your Git configuration or in a .lfsconfig file, you may set either or both of lfs.fetchinclude and lfs.fetchexclude to comma-separated lists of paths. here's the rules, bestie:

  • if lfs.fetchinclude is defined, Git LFS objects will only be fetched if their path matches one in that list
  • and if lfs.fetchexclude is defined, Git LFS objects will only be fetched if their path does not match one in that list

Paths are matched using wildcard matching as per gitignore(5). iykyk. πŸ¦‹

⭐ note that using the command-line options -I and -X override the respective configuration settings. and setting either option to an empty string clears the value. she said "no value, no problem." πŸ’…

πŸ‘‘ DEFAULT REMOTE πŸ‘‘

Without arguments, pull downloads from the default remote. The default remote is the same as for git pull, i.e. based on the remote branch you're tracking first, or origin otherwise. so she just knows where to go. main character instinct. ✨

πŸŽ€ SEE ALSO πŸŽ€

git-lfs-fetch(1), git-lfs-checkout(1), gitattributes(5), gitignore(5).

Part of the git-lfs(1) suite. 🫢


and that's the whole page, bestie!! πŸŒˆπŸ’– this one's GIT-LFS-PULL(1) from the git-lfs(1) squad β€” mwah, go download your files, you deserve them. πŸŽ€πŸ¦‹βœ¨

πŸ“¦ where this page comes from