Polytonic / Glitter

Dead Simple OpenGL
http://polytonic.github.io/Glitter/
2.46k stars 416 forks source link

Shallow clone of submodules. #45

Open chengluyu opened 6 years ago

chengluyu commented 6 years ago
image

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?

Polytonic commented 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?

chengluyu commented 6 years ago

@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.

chengluyu commented 6 years ago

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...