You can use the --above option to git lfs migrate import to migrate all files that at the specified time are larger than a certain size. However, if your files change to be smaller or larger in the future, or you add more files in the future that are larger than the limit you specified, you will have to track them manually.

For these reasons, we recommend using patterns rather than --above.

On older versions, set GIT_LFS_SKIP_SMUDGE to 1 and run git lfs pull to pull down the LFS files. This bypasses Git’s smudging functionality and therefore avoids its limitations.

Normally, if you’ve run git lfs install at least once for your user account on the system, then Git LFS will be automatically invoked by Git when you check out files or clone a repository and this won’t happen. However, if you haven’t, or you’ve explicitly chosen to skip that behaviour by using the --skip-smudge option of git lfs install, then you may need to use git lfs pull to replace the pointer files in your working tree with large files.

There are also several other possible ways to encounter this problem, such as an incomplete migration of your repository. For example, you should not use git lfs track to track patterns that are already in your repository without running git add --renormalize ., since that can lead to this problem.

Users frequently find that this cannot be changed by doing git reset --hard or other techniques because Git then checks the files out and marks them as modified again. The best way to solve this problem is by fixing the files and the committing the change, which you can do with the following on an otherwise clean tree:

$ git add --renormalize .
$ git commit -m "Fix broken LFS files"

This requires that every branch you want to fix have this done to it.

To prevent this from reoccurring in the future, make sure that everyone working with large files on a project has run git lfs install at least once. The command git lfs fsck --pointers BASE..HEAD (with suitable values of BASE and HEAD) may be used in your CI system to verify that nobody is introducing such problems.

If you skip this second step, then you’ll end up with files that are marked as LFS files but are stored as Git files, which can lead to files which are always modified, as outlined in the FAQ entry above. Note also that this doesn’t change large files in your history. To do that, use git lfs migrate import --everything instead, as specified in one of the entries below.

$ git config --global diff.lfstext.textconv cat

Any given .gitattributes entry for large text files can be customized to use this global text converter (e.g., patch files), whereas binary formats can continue to use the conventional lfs diff tool, like so:

$ cat .gitattributes
....
*.bin filter=lfs diff=lfs merge=lfs -text
*.patch filter=lfs diff=lfstext merge=lfs -text
....

Be advised that all developers sharing this repo with such a modified .gitattributes file must have similarly configured the lfstext text converter, whether globally or on a per repository basis.

This also rewrites history, so the Git object IDs of many, if not all, of your objects will change.

To fix this, you can use git lfs migrate import --everything with an appropriate --include argument. For example, if you wanted to move your .jpg and .png files into Git LFS, you can do that with git lfs migrate import --everything --include="*.jpg,*.png". More complicated patterns are possible: run git help gitattributes for more information on valid patterns. Note that if you’re specifying directories, using slashes is mandatory: backslashes are not allowed as path separators.

The easiest way to solve this problem is by using the --skip-repo option to git lfs install, which skips the installation of the hooks. Despite the name, it can be successfully combined with --local if you need that option.

Note that this prevents things like git push from pushing LFS objects and locked files from being read only, since those are implemented by hooks. If you need that functionality, you should review the Jenkins documentation about how to properly configure the environment in such a situation so that hooks can be used.

Since Git LFS doesn’t even get invoked in this case, there’s no way to change how this works. If you just want to include the single subdirectory without stripping the prefix, you can do this: git archive -o archive.tar.gz --prefix=archive/ HEAD src. If you do want to strip the subdirectory name (src) in this case, one option if you have the libarchive tar (available on Windows and macOS as tar, and usually on Linux as bsdtar) is to do something like this script:

#!/bin/sh
# With trailing slash.
ARCHIVE_PREFIX="archive/"
# Without trailing slash.
SOURCE_PREFIX="src"
# Without directory or file components.
REVISION="HEAD"
temp=$(mktemp -d)
git archive --prefix="$ARCHIVE_PREFIX" "$REVISION" "$SOURCE_PREFIX" | bsdtar -C "$temp" -xf -
bsdtar -s "!^\./!$ARCHIVE_PREFIX!" --format=pax -czf archive.tar.gz -C "$temp/$ARCHIVE_PREFIX$SOURCE_PREFIX" .
rm -fr "$temp"