We are using gitsubmodules (SM). We have several big superprojects (SP) that contain a lot of SM and nested SM. For each repo (SM or SP), we have a master, a develop and some feature branches.

My question is the following: Shorter is better as speaking of branches, but in the case we are building in a first SP a disruptive feature (that breaks SM interfaces with the other SP), how could we handle such painfull integration with the other SPs?

• shall we wait for all superprojects to be compliant to the feature before merging this feature into develop branches of SM?
• shall we merge the feature with the develop branches of SM and then "force" other SP that want to be on the develop SM branches to be compliant to the new feature, or create their own temporary branches if they don't have time (because of an ongoing release) to merge their project with the new feature.

CodePudding user response：

Ditching SM in favor of separate git-repos reduces a lot of pain and timewaste.

Two of those disruptive events alone should take more time than doing the split (regardless of amount of SM).

Apparently it happens rarely, i.e. the SM-usage/interfaces stay stable, meaning easier to split.

CodePudding user response：

Your first bullet point seems like a better option, because in your second you risk introducing breaking changes for an indefinite time.

However, in these scenarios its really hard to avoid breaking changes so then, I think it really comes down to what your smallest testable unit is. Look for whether your SP is testable without any of the SMs or are there certain SMs that are independent of the SPs, then go with those first.

Side-note: If your project and submodules are adhering to the dependency inversion principle, this should be fairly easy. You would start with merging the high-level modules first.