Open chengluyu opened 6 years ago
Hmm. The Glitter/Glitter/Vendor/...
folder is 372.8MB on disk for me. Are you referring specifically to that subdirectory, or are you referring to the total folder size (as measured from/including the root of the repository)? Per this StackOverflow post you can try these commands:
git reflog expire --all --expire=now
git gc --prune=now --aggressive
It looks like git
also now supports a --depth
option, i.e. something like so:
git submodule update --remote --recursive --depth 1
There also seems to be a new shallow = true
submodule config option. I'll test that locally and see if it makes any difference. Let me know if any of the above worked for you?
@Polytonic
Thanks for your instant reply. I've tried that before I wrote this issue. But none of those works. The command git submodule update --remote --recursive --depth 1
failed because the HEAD of some submodules is different from the version Glitter uses. I also set the shallow
options of those submodules to true in submodule config. But strangely it didn't work.
The Glitter/Glitter/Vendor
folder is around 380 MB, while the whole Glitter
folder is over 700 MB because the commit history / branches / revisions info of those submodules are stored in .git/modules/Glitter/Vender
. What I want to achieve is to clone submodules without those extra objects.
Hmmm. I found the reason why shallow clone fails.
Glitter refers old commits of submodules. But both specifying shallow=true
in .gitmodules
and using git submodule update --remote --recursive --depth 1
retrieve the latest commit. So the referred commits cannot be found in cloned submodules, which causes failure.
As described in #37, the latest assimp causes build failure so update all submodules is not feasible.
I think manually clone specific commits of submodules is fine, but that's too tricky...
After recursive clone I found the folder become so huge because clones of submodules contain commit history and revisions. Is there any way to clone submodule shallowly?