loading...

re: Git Submodules Revisited VIEW POST

FULL DISCUSSION
 

Thanks for this. When I was looking into git modules I found very few resources truly going deeper than "meh, I wouldn't use them".

 

Yeah, that was pretty much the conversation at Surevine. I was actually thinking of digging into the Git source code and making it do what we needed, so finding this has saved the world from my code.

 

I don't get why more people don't use submodules. The source repo updates, you update your submodule and it gets used in your code. You don't even HAVE to update submodules, but you still get the benefit of having the exact commit hash of the version you're using, whether it's development or stable. Why would you NOT want to do that?

 

It may be okay for third-party dependencies. But when you add something your team actively develops (like a library shared between projects) then submodules may become a hassle.

Switching branches git branches in the main repo does not update the submodules. When you run git status in the main repo it does not show what changed in the submodules. In general, all git commands are now current-directory-aware. It becomes a hassle. And this does not trip into code review, where with web UIs like GitHub/GitLab/Bitbucket if you want to make a change to the submodule and to the main repo you have to create several separate pull requests.

And now, drop transitive dependencies into the picture.

I think you mixing up with submodule and pull request. Pull request is a "big" issue for productivity. Not the submodule. So what you describe is the result of ineffective pull request style.

Using submodule as any tool have side effect. It's hard side effect (to me) would be the selection of a wrong branches where it can be rebase freely. This would make a commit disappeared.

code of conduct - report abuse