So I started using git submodules. It seems I've walked into something unexpectedly cumbersome.

I understand you. I'm never sure if I have set them up correctly until my recent changes in the submodule don't show up.

I had a similar experience. I figured it out eventually, but since then I haven't had a use case with a net positive benefit vs hassle value - considering other members on the project might not be comfortable with it either.

@ltlian what was your alternative? In my case we have separate applications, like a rest API and some other applications that consume it.

If it is a monolithic app, then you can make the submodules as a dependency (maven or npm) and include them in the main app. If it is a typical multi-tier app, then you can make separate repos for each tier (web - middleware - backend). In your case, you can have one repo for each application and provide the consumers only your REST api's contract.

@ars1 We just use separate repos. Having to pull the different ones hasn't been an issue for us so far and we don't have compile time dependencies between them, being microservices and a couple frontend apps.

There are still arguments for structuring it via submodules, but for this project it would just be "neat" without solving any issues.

The number one mistake in submodules ist the expectation that changes in a submodule are 'loaded magically'

git submodule update --init

vs

git submodule update --init --remote

It's correct and expected behaviour for many reasons....

But whenever I explained people this behaviour who were new to git submodules I saw... Tremendous confusion.