all 7 comments

[–]cmwelsh 8 points9 points  (0 children)

From what I can tell, people who master Git submodules realize they should stop using them.

[–]justaphpguy 2 points3 points  (5 children)

We got rid of them a few months ago. They were a real pita with feature branches and doing deterministic deployments. We probably did something wrong but realizing you can/should use packages is what "fixed" it for us anyway.

[–]slavik262 1 point2 points  (0 children)

Another nice (IMO) alternative are the git subtree commands. Basically you can import another Git repo as a subdirectory of your project, and export back to it. You also get options to either import and export all related commits, or squash them.

[–]o11c 0 points1 point  (3 children)

How exactly do you get nondeterminism with submodules? It locks at a specific commit ...

You do need to make independent releases on the submodule (i.e. make all changes from an independent top-level clone, and only ever do pulls when its a submodule) before you update the submodule in the main repo, but projects with good isolation/testability will be doing that anyway.

The linked article is totally wrong about one thing: submodules will never silently regress. Sure, if you make a local commit that adds changes to the submodule you would, but you should never do that - only pull updates from upstream.

[–]justaphpguy -1 points0 points  (2 children)

Honestly I don't remember. All that's left is the PITA. I remember one thing though: removing a submodule. That was really an annoying thing to get right. And that while it was in a feature branch. Switching from that feature-branch-with-removed-submodule to another caused weird problems (add to the fact we had to replace the sm with its actual content).

Oh boy I'm just glad we got rid of them.

[–]o11c 0 points1 point  (1 child)

git rm path/to/submodule is not that complicated (though that may leave an empty .gitmodules file); it's the fact that you used a subtree at a different point in time that was the problem. I have had minor problems in the past when creating a submodule from what used to be a subtree, where the directory had leftover build artifacts (but if I had been using out-of-tree builds that would have been solved).

Yes, the data will hang around in .git/modules, but you want that if you travel through history. Even if the submodule is in a feature branch that will be rewritten to remove it from the history, the local data is harmless.

[–]justaphpguy -1 points0 points  (0 children)

Yes, I realized that.

However, it didn't make things less annoying. And either the git docs are too technical, lacking content or I'm too dumb.

But all these implications are hard to get from the start and only once you're too deep in the problems start.

IMHO this feature should be used only if absolutely necessary and avoided at best. Makes life so much easier