Open juniordiscart opened 5 years ago
Hey, thanks for writing in.
I think you've already identified the problem, which is that you have some very large Git blobs. I expect what happened is that somebody committed large blobs without using Git LFS, and as a consequence they got written into the repo as Git objects instead of LFS objects. This can happen if a user doesn't have Git LFS set up properly on their system when they commit (e.g., they haven't run git lfs install
or an equivalent).
You can, of course, rewrite history with git lfs migrate import --everything --fixup
, which will rewrite each commit to use the .gitattributes
file in that commit to determine which files should be written as LFS objects. This will likely shrink your repository back down to a normal size, but of course it has the downside that all the Git object IDs will change.
@bk2204 Thanks for your answer. I didn't ran the --everything --fixup
combination before. However, I tried variants on it, including all of the branch name using the --include-ref= options.
git lfs migrate import --everything --fixup
migrate: override changes in your working copy? [Y/n]
migrate: override changes in your working copy? [Y/n] Y
migrate: changes in your working copy will be overridden ...
migrate: Sorting commits: ..., done
migrate: Rewriting commits: 100% (50/50), done
branch1 3eaef984d212ad8922d76f0b7459b107e735e8c7 -> 3eaef984d212ad8922d76f0b7459b107e735e8c7
branch2 9cb2cddc56ad246143db150d8f7be4d9cf4cccc6 -> 9cb2cddc56ad246143db150d8f7be4d9cf4cccc6
branch3 fd102c23eb6e3583f209e57df231aa431f602621 -> fd102c23eb6e3583f209e57df231aa431f602621
branch4 b8f7d0d1ae921df95888de90b5d1162da6fd73bf -> b8f7d0d1ae921df95888de90b5d1162da6fd73bf
master de27c4f054b0dff8e1fa029cde207311ed4c84b6 -> de27c4f054b0dff8e1fa029cde207311ed4c84b6
migrate: Updating refs: ..., done
migrate: checkout: ..., done
As you can see, the output didn't change much about the repo (I guess the -> indicates that something should have changed if it did do something).
Do you perhaps have any idea of a command to find the blobs in a pack to which commit they are attached to?
Hi
We used to host our pretty large Unity project on Unfuddle, but it kind of took too long to commit stuff since the repo grew so large because Unfuddle doesn't support LFS. I migrated our project to BitBucket which has LFS and this went well initially. I took a snapshot of the project, setup git completely from the beginning again and tracked the files using git LFS. around ±50GB was stored in LFS and the repo size was ±70MB. Nice!
Now, somewhere down the line, the repo size is now back at 1.88GB, and we are nearing the 2GB repo size limit before it goes into read-only mode and I can't figure out which files are causing the repo to grow. If I run
git lfs migrate info --everything
I get the following output:Which, when adding up, is about the size I expect, but if I run
git count-objects -vH
I get:I imagine BitBucket still has some garbage collection to do to reduce the size to 1.32GB. If I run a script to find the largest files that are in the pack (found here: https://stackoverflow.com/questions/10622179/how-to-find-identify-large-commits-in-git-history) I get output:
If I check the size of this largest file, I know it isn't the largest file in the project. The largest file in the project is being tracked by LFS (it's a .tiff file over 500MB).
My .gitattributes are as follows (and as you can notice, .asset and .unity are tracked)
You may notice that .unity and .prefab are present twice in the file. The lowest two lines have been added after I ran the migrate import command.
Hope someone can help me determine what's wrong and how to get my project back on track. Git lfs version that's been used:
git-lfs/2.7.1 (GitHub; darwin amd64; go 1.12)
Thanks in advance!