Move Git LFS tracked files under regular Git

git lfs migrate
sourcetree git lfs
git lfs migrate import
git lfs migrate export
git lfs clone
lfs upload git
git lfs untrack single file
github file system

I have a project where I stored video files with Git LFS. Now I ran into some complications with my build server that doesn't yet support Git LFS. As it's an external service, I can't really affect the build process, and thus would want to move the files from under Git LFS back to "regular" Git. I managed to untrack the file types with git lfs untrack '<file-type>' but git lfs ls-files still gives a list of the files previously added.

I imagine I could remove the files, push the changes and then manually re-add them, but is this really the recommended way of doing things?

I have just recently run into this problem where assets were accidentally added to git-lfs on one branch that shouldn't have been. My solution was:

git lfs untrack '<file-type>'
git rm --cached '<file-type>'
git add '<file-type>'
git commit -m "restore '<file-type>' to git from lfs"

The result is a rewrite of the git-lfs oid sha256 pointers with the standard file contents.


(Edit 2019-03): The accepted answer was changed to provide an easy solution for simpler cases. See also the edits in the answer by VonC for alternate solutions in case you have a more complex case on hand.

Moving a file in your repository to Git Large File Storage, If you've set up Git LFS, and you have an existing file in your repository that Git LFS and configuring Git LFS tracking, you can move files from Git's regular  If you've set up Git LFS, and you have an existing file in your repository that needs to be tracked in Git LFS, you need to first remove it from your repository. After installing Git LFS and configuring Git LFS tracking, you can move files from Git's regular tracking to Git LFS.

Tutorial · git-lfs/git-lfs Wiki · GitHub, Now let's add some large files to be tracked by git-lfs: to your git repository. git lfs track stores the tracked files patterns in .gitattributes . To make this possible, Git LFS ships with a git lfs migrate command that allows for Once git lfs is installed, to clone an LFS repo, just run a normal git clone command Moving a file in your repository to Git Large File Storage If you've set up Git LFS, and you have an existing file in your repository that needs to be tracked in Git LFS, you need to first remove it from your repository. After installing Git LFS and configuring Git LFS tracking, you can move files from Git's regular tracking to Git LFS.

As of Git 2.16 (released Jan 17th, 2018), you can do this easily with the --renormalize flag of git add:

git lfs untrack '<pattern>'
git add --renormalize .
git commit -m 'Restore file contents that were previously in LFS'

From Git's documentation:

--renormalize: Apply the "clean" process freshly to all tracked files to forcibly add them again to the index. This is useful after changing core.autocrlf configuration or the text attribute in order to correct files added with wrong CRLF/LF line endings. This option implies -u.

The key part here is "all tracked files". Normally, filters are only run when a Git operation changes a file in the work tree. Changing the LFS whitelist in .gitattributes isn't a Git operation, and so the index ends up in an inconsistent state after you run git lfs untrack. Running git add --renormalize . tells Git to re-run filters on every file in the repository, which ensures that all files which should be in LFS are—and that all files which shouldn't be aren't.

Best practice for migrating an existing Git repo to support LFS , I'd like to give Git LFS a good crack with our existing ~25GB Git repo but I'm at a bit of a loss Filter-branch to convert all tracking over to lfs git lfs track "*.npy" git add .gitattributes .gitconfig for file in $(git ls-files | xargs git check-attr It appears it is not, it says compressing objects, writing objects as usual. Currently git lfs ls-files by default lists the files at the current HEAD, but excluding the new files in the staging area. This is inconsistent with the behaviour of git ls-files which by default lists also the new files in the staging area.

I had problems doing steps in Windows. To remove all git lfs tracked files and restore original file I did the following in git bash:

  1. Removed .gitattributes

  2. git lfs ls-files | cut -d ' ' -f 3 > lfs-files.txt

  3. Execute following snippet:

Snippet:

while read file; do
  git lfs untrack "$file";
  git rm --cached "$file";
  git add --force "$file";
done <lfs-files.txt

Workflow when reverting LFS tracked files · Issue #957 · git-lfs/git-lfs , This basically meant that I needed to get LFS to untrack files that were there's no obvious way to move a subset of previously LFS-tracked files out of LFS. You could try running this in a Git Bash env on Windows, instead of  Even though the question concerns files that have not been commited, let me suggest a solution to list the files tracked by git but not git-lfs after commit, which you can do by concatenating the list of files tracked by git (git ls-files) with those tracked by git-lfs (git lfs ls-files | cut -d' ' -f3-) and then only take the files that are unique in this list:

You can't really remove anything from GIT LFS, and although the solutions presented here may work (with modifications), they require a lot of effort and may have side effects on your repository.

If you arrived here, it is time to ask yourself whether you want to manage your large files with GIF LFS and whether GIT itself (which is inherently bad at managing large files, because it is a distributed version control system) was a good choice.

If you have many large files and you are a single organization working on your project, something like Subversion may work better for you.

Git LFS, How to migrate an existing Git repository to Git LFS with BFG. However, simply adding the large files that are already in your repository to Git LFS, will not and lastly create LFS tracking rules to prevent new binary files from  @gessulat That's because the tutorial has you run git add on the *.bin files before running git lfs track. The track command doesn't apply retroactively to files, and the tutorial mentions using BFG to update existing files.

Migrate a Git repo into Git LFS with BFG, I tried to stop using Git LFS, but found no way to revert my previous tracked pointer files using git lfs uninit, git lfs untrack, git rm after I move those files back it  GitHub's current suggestion is to use a tool called The BFG to completely strip all existence of the file from your repo. Presumably it'll then be removed from the lfs storage when git's garbage collection is next run by Github.

Move Git LFS tracked files under regular Git - git, The ´import´ mode migrates large objects present in the Git history to pointer files tracked and stored with Git LFS. It supports all the core ´migrate´  git lfs track '*.bin' git add .gitattributes git commit -m "Track .bin files" git tag not_working Just tracking files does NOT convert them to lfs. They are part of history already, the only way to convert old files is to rewrite history (see the section about migrating existing data ).

git-lfs-migrate(1) — git-lfs — Debian unstable, Dealing with huge files in such coding projects involves dealing with version… Hopefully, it is possible to use Git Large File Storage (Git LFS) as a simple with Git LFS always asking your password for every file tracked by LFS, will be named the_git_project.git and that the normal clone gets its folder  What is Git LFS? Git is a distributed version control system, meaning the entire history of the repository is transferred to the client during the cloning process. For projects containing large files, particularly large files that are modified regularly, this initial clone can take a huge amount of time, as every version of every file has to be downloaded by the client.

Comments
  • With .gitattributes is set up correctly to track the files I want, this solution worked beautifully. Much simpler than some of the other solutions posted.
  • This worked wonderfully. Should be listed as the true answer.
  • worked for me in '18. tip for others: 'file-type' was '**.jpg'
  • @OlliNiskanen while it is gratifying to be marked as the accepted answer, I feel it important to note that while this is a good and simple solution to the specific question asked, for more complex cases readers should consult the batching methods suggested in the edits by tstephens619 and ttaylorr to VonC's answer.
  • @mred, Agreed. I suggested an edit that links to the previous accepted answer. This answer was pretty buried and people found it helpful, so I feel this should stay as the first thing visitors see.
  • Thanks for finding the correct issue from the project. Still, even this solution requires moving the files manually. Seems sort of odd when the workflow from Git to Git LFS is basically git rm --cached <file> -> git add <file> -> git commit as long as you have the tracking set up correctly.
  • @Klipi I agree: it seems the untrack scenario is still perfectible.
  • @Klipi Good call. I will monitor it.
  • My version of LFS (2.0.2) doesn't have a uninit command. Instead of git lfs uninit I had to use git lfs uninstall.
  • The good thing about this method is that if you checkout from the past or another branch, the old lfs stuff is still there. But going forward it is not using lfs any more. The one thing I would add, is to remove the lfs stuff now from .gitattributes (or in my case deleting the whole file) and checking that in too.
  • @ericfrazer Every single visit to this question proves my point, as following the official documentation of GIT LFS, removing files from LFS should be a no-brainer. Except, it isn't, because it does not work. People are struggling, because of a combination of a) it is hard to fine-tune what files to add and b) adding many small files has performance issues on Windows because GIT LFS runs as a sub process, and starting sub processes is expensive without fork(). Bottom line: For your own mental sanity, don't use LFS before all of this is fixed. Which hasn't happened for years now...