Cloned repository doesn't contain LFS object content
プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。
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.
*Fisheye および Crucible は除く
問題
When cloning a repository you may find some or all of the files you track via LFS only contain the LFS pointer. For example:
$ cat image.jpg
version https://git-lfs.github.com/spec/v1
oid sha256:eed08a1edb5eeea08ea4eb14619ac8494342ba3fd24bd4b423b4c3cf1427fb9b
size 951986
原因
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
.gitconfig
file - Cause 2: The
.gitattributes
file does not contain a pattern matching the file
ソリューション
原因 1:
Ensure your ~/.gitconfig
file contains the "lfs" filter lines:
[filter "lfs"]
clean = git-lfs clean %f
smudge = git-lfs smudge %f
required = true
If these are not present it is a simple matter of running the command: git-lfs install
原因 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:
$ 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.