Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
p100sch1460217dI understand you. I'm never sure if I have set them up correctly until my recent changes in the submodule don't show up.
ltlian2046217dI 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.
noder1275217dIf 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.
ltlian2046217d@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.
IntrusionCM5904217dThe number one mistake in submodules ist the expectation that changes in a submodule are 'loaded magically'
git submodule update --init
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.