We currently have a SVN repo structured like so
/trunk/library/libA
/libB
/libC
.
.
/trunk/tools/toolA
/toolB
.
.
(it is more complicated than that, but this is sufficient to describe my issue)
I want to migrate this to git, but am facing a challenge. One developer highlighted that he often needs to make changes to libA, which may result in changes to libC and toolA (in fact around 4 different projects might need to change). Understandably he says that with SVN he just commits the library folder and all his changes get committed without having to go into each folder and do a separate commit.
With git, I would choose to have one repo per library, but he believes having to keep track of changes across projects like that would be error-prone. I do appreciate that if you had to make changes to 5 repos to fix a single bug, or add a new feature, it would be time consuming, and you might forget to add a change.
So as I see it I have some choices:
Group projects that frequently change together into a single git repo with subfolders. i.e. a
library.gitrepo. For exampleLibA'/libA /libC /libFRefactor the projects to bring code with higher cohesion together into a single project
These are not my projects and the original author(s) have since left. To me the fact that seemingly unrelated projects frequently affect changes in each other isn't good design. I'd thus favour the latter choice, if it proves feasible.
I'd like to get some advice on the best strategy for this, which of my two suggestions is preferable, do I have other options, or should we just tell the developer to get over it?
