Florian Winter
Florian Winter

Reputation: 5279

Files are still (not) in GIT LFS after changing .gitattributes

When using GIT LFS, .gitattributes controls which files are managed by GIT LFS and which ones are not. According to the documentation, all it takes to move files between GIT LFS and regular GIT storage is to change .gitattributes.

I have modified .gitattributes in a Bitbucket repository, but git lfs ls-files still lists the same files as before, including files that should no longer be managed by GIT LFS and not including files that should now be managed by GIT LFS. Also, committing and pushing the change in .gitattributes is suspiciously fast.

Is there a command that I can (or have to) run to update the GIT LFS status of all files and move them to the correct storage?

Upvotes: 6

Views: 4434

Answers (2)

vauhochzett
vauhochzett

Reputation: 3387

The issue is that git lfs track actually does two things:

  1. It adds a line to the .gitattributes file
  2. It updates the file's timestamp to ensure that it will be converted

When manually editing the .gitattributes file, you only do step 1. As the file does not change, Git will not trigger LFS to convert the file.

To solve this, you can force Git to re-add the file, and thereby convert it to an LFS pointer:

  • git add --renormalize --all to check all files in the repository
  • or, e.g., just run git add --renormalize "**.ext" to only check files with a specific extension

(source)

Upvotes: 3

cdytoby
cdytoby

Reputation: 879

Well, it seems that git lfs have to be used like git lfs track something.bin, and manually change .gitattributes won't really add exist files to LFS.

If you manually modify the .gitattributes file, my solution is:

After modify the file, run these commands:

git rm --cached -r .
git add -A

It may take a while if there is a lot of files. But it does the trick.

Upvotes: 6

Related Questions