If your projects get busy enough You know you will get in trouble with this one eventually. The responsibility of not mixing super and sub-project code in commits lies with you.

Contributing code back upstream for the sub-projects is slightly more complicated.This actually will break every sophisticated git workflow if you haveĪutomated scripts doing things or are doing any advanced git workflow You must learn about a new merge strategy (i.e.In my opinion the drawbacks of using git subtree are not acceptable: Will explain and solve themselves eventually when your basics are solid. The project from further away and reflect a bit more on dev operations such problems Is not Your git strategy but overall compliance to logical workflows. If you are occurring such problems in your teams the real culprit So this class of problems is actually lack of understanding and discipline instead ofĭrawbacks to software. The changes to the submodule must be released (i.e.: pushed to the upstream repo) before the Of course you have the flexibility of doing it but when committing This also means that it actually is non standard procedure You have to be concious about the fact that the submodules must have a separate You can't go along and treat the whole repo as one Project one has to comprehend the consequences. Of course just rollback that commit but that isn't the point here. That is very unfortunate indeed isn't it? Still one can

If the submodule repo hasn't been pushed to and the changes only exist on the local machine The new commits to the master repo will also have to pull the changes to the submodule. Version of the submodule will, correctly, also propagate to the including repo. This happens when someone updates a submodule on his instance This is people missingĪ version bump of a submodule. In nature another variation of the this code doesn't exist! problem. Even if you are not experienced all you have to do is look at the This of course isn't a big issue most experienced users can easily cobble up a manualįetch of submodules via the cli. Not using git via ssh or git protocol or not authenticating viaĬertificates can lead to states where submodules don't come automatically when checking out a Underlying transport protocols work tend to get lost in submodule hell. This presents itself when People who don't understand how git and the As analysis will show they actually boil down to one specific problem that isn't even near the software layer. Actually the criticism itself only ever came from younger developers who still weren't completely eloquent with things like Unix, protocols and VCS.Īfter collecting my thoughts for a while and reading up on our own past research, two big issues come to mind. From time to time a less experienced new hire might come up with questions and the idea to scrap git submodule altogether but that's about it. We also never had any of the problems that many people seem to advertise. Now some years later we still are using submodules. Many times we launched into deep research and review procedures investigating all these claims. In my role as a technical lead at Glanzkinder I was more than once confronted with similar argumentation. Many well known developers seem to cater to the opinion that a native submodule primitive in a VCS is somehow a bad thing and start wildly proposing alternative solutions. A lot has been said about git submodules lately.

Git submodule alternative