If it helps, the output for these files always had something like (Git: edee1ad) after each file name. However, after attempting to push to, I realized that it was clearly not the case. For example, when I ran git lfs status, it showed me a ton of files under Git LFS objects to be committed, making me think they would be added to Git LFS. It's not clear which one I should be using and what output I should be looking for. I see two related commands that might help: git lfs status and git lfs ls-files. This'll allow me to iterate and try new things. Sure, I'd love to know the proper format, but more importantly, before I attempt to push my changes to github, I'd like to verify that the match and files do indeed work correctly. I tried both and they didn't use git lfs for storage. This answer says the proper format is git lfs track "MyProject/Frameworks/**", but Atlassian's help document says I should use git lfs track "MyProject/Frameworks/". I'm not sure what the proper format for matching all files and folders recursively under the Frameworks folder is. That could be explained by not having git lfsinstalled.I'm trying to add everything under MyProject/Frameworks/ to git-lfs (large file storage). That your files in test-data/ still contains the good content but what you report is what a git command show you.Ĭould you confirm? Or you have a problem. I hope that what you said is partly false. I hope you better understand how it works. git/lfs/objects will still grow in the future every time a new version of these files is downloaded (but it should always stay smaller than if you didn't use git lfs). And now, your local repository should be smaller.īut the folder. To see the real effect of git lfs on your local repository, once you -force pushed the new history (and that the old one is no more in the remote repository), I will do a fresh clone. git/lfs/objects serve as a cache folder so once you pushed all the new history and so it uploaded the files managed by lfs, you could delete it to reduce the size of your repository. git/lfs/objects because you made the git lfs conversion. But do that once you are sure your lfs migration is a success) and in. git/objects until you ditch the old history (by purging the reflog and doing a git gc. I also think it double the size of your repository because the objects are stored twice for the moment. I am confused.īecause all the files managed by git lfs are stored in this folder it could become huge. git folder becomes twice as large (400MB to 800MB). And these objects will be uploaded to the server when you will git push.Īnd the. The content of the file is stored in the. Instead of committing the file in the repository, it commit a this "pointer" file that contains the id of the object. Because for the file managed by git-lfs, only the files that should appear in your working directory will be downloaded during the git checkout.Īll of the files in the test-data/ directory are replaced with files that look like this:
The promise of git lfs is not that your repo will be smaller but that when you clone, you won't have to download all the git objects so the clone will be smaller and faster. This means that the repo should get smaller, because it doesn't directly contain all versions of large files. I thought that git lfs migrate rewrote the history of a repo so that specified large files were kept in LFS.