Cloned repository doesn't contain LFS object content
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
When cloning a repository you may find some or all of the files you track via LFS only contain the LFS pointer. For example:
1
2
3
4
$ cat image.jpg
version https://git-lfs.github.com/spec/v1
oid sha256:eed08a1edb5eeea08ea4eb14619ac8494342ba3fd24bd4b423b4c3cf1427fb9b
size 951986Cause
This is a client issue, and is a problem specific to HTTP/S remotes. The most common cause of this is that the LFS filters have not run.This can be cause by:
Cause 1: LFS filters are not setup in your
.gitconfigfileCause 2: The
.gitattributesfile does not contain a pattern matching the file
Resolution
Cause 1:
Ensure your ~/.gitconfig file contains the "lfs" filter lines:
1
2
3
4
[filter "lfs"]
clean = git-lfs clean %f
smudge = git-lfs smudge %f
required = trueIf these are not present it is a simple matter of running the command: git-lfs install
Cause 2:
In order for the LFS filter to run over, for example, the above mentioned image.jpg file, the file must be "tracked" via LFS. The following example shows the case where all files ending with the jpg extension are tracked:
1
2
3
$ git lfs track
Listing tracked paths
*.jpg (.gitattributes)It is common for users, who track a new file type, to forget to commit their updated .gitattributes file.
Was this helpful?