to be fair, #2 exists because monorepos and submodules are somewhat antithetical concepts. A monorepo is supposed tobe the single source of truth for the codebase, while submodules are pointers to external repos with their own history. That alone will increase the source of churn for teams that are constantly merging.

1. git rebase and last commit amending.

2. That has the smells of a wrong code architecture. If change request leads to unneeded code conflicts, you need to rework your code architecture.

3. That’s valid, but why not create libraries out of those modules?

4. Valid. But I think the issue is on the agent side. Git has already all the features to make those happen, it’s the agent that is not integrated with git.

5…

6. Either than sweeping changes (adding a formatter, changing config,…) There’s no need for formatting changes to be its own commit in the main repo. I usually add a check to prevent inconsistent formatting.

7. The git history has the previous username and email recorded alongside each commit.