Git LFS refused to track my large files properly, until I did the following

New Solution

The original solution is from 2016. Tech progresses…

Seems the best solution now is

git lfs migrate

Thanks to @iff_or for alerting me to this (see comments).

Outdated Solution, don’t use

I then discovered a few fixes, some of which seem to be bugs, some of which simply were not obvious to me.

  1. It seems that in order to use lfs with an existing repository, a hack or third party tool such as BFG’s converter is needed.

    • I did not want to go that route, so I simply initialized a new repository locally, then did the challenge of hooking it back up to the real repo.
    • I created a new directory, then git init, etc.
      • In my case, the remote repository was GitHub. So I did all those proper hookups like git remote add origin [email protected]:<my_id>/<my_repo>.git
  2. Also, while Git’s Training Video claims that you can simply specify a folder, such as "my_folder/", I could not get this to work. Therefore, I just cleverly used filename extensions to manage things.

    • For example, git lfs track "my_folder/" would not work for me, but git lfs track "*.zip" did work.
  3. I had no luck getting LFS files to be identified correctly unless I had first updated the .gitattributes file, and committed and pushed that new file to the remote server.

    • git lfs track "*.zip"
    • git add .gitattributes
    • git commit -m "Updated the attributes"
    • git push
    • git add my_large_file.zip
    • git lfs ls-files
      • And here I would ensure that I saw my_large_file.zip being tracked.
    • git commit -m "Now I am adding the large file"
    • git push

It’s possible that some of the things work, and I was simply doing them wrong. However, following the witchcraft described above finally got LFS to work, so I thought I’d pass on these details for others, in case someone else had the same problem.

Leave a Comment