Glitter icon indicating copy to clipboard operation
Glitter copied to clipboard

Shallow clone of submodules.

Open chengluyu opened this issue 6 years ago • 3 comments

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?

chengluyu avatar Apr 21 '18 07:04 chengluyu

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 avatar Apr 21 '18 07:04 Polytonic

@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 avatar Apr 21 '18 08:04 chengluyu

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

chengluyu avatar Apr 21 '18 09:04 chengluyu