Disadvantages for having completely different codebases in different git branches

Question

One senior member of my team setup a new git repository for our product we are working on, since we are migrating from SVN to git. Our product consists of different software components that are working more or less completely independent and are also completely different in terms of code. On SVN, these components were all tracked in a single SVN repository with different sub folders for each component and each folder/component was branched separately if needed.

With that background in mind, he setup the git repository with different branches that contain the different components of our product to avoid having the problem, that in git, you cannot branch single folders but only the whole repository at once I assume. So now we just branch the branches.

For me this feels kinda odd since I never saw a repository that was setup this way. I would have created different git repositories for the different components. If everything must be in a single repository I would have used git submodules. But these ideas do not change his opinion.

The problem is, that I cannot really find a strong argument against this approach. As far as I understand, technically this is completely doable and possible with git... The only argument I have is, that SVN is not git and this is not really the git way of doing things. And we will probably run into issues, when we later want to split up the repository into multiple ones.

So are there any strong disadvantages besides the ones I already mentioned?

Answer 1

First, I just want to say I don't understand why you are migrating if they don't want to use git like git.

I agree with you that it's workable, and it's not even that problematic to split it up later. You would basically just duplicate the monorepo and delete the branches you don't want in each copy.

The main concern I would have is dealing with the gazillion branch names, but that's not any worse than what you've been dealing with in svn. Your pulls are probably also slower, but only marginally. Also, you're likely to have friction with third-party tools like CI that expect a more standard setup, but again, probably nothing you can't work around. It's more difficult to control things like push access per branch than per repo, but that may not be a concern at your company. It's going to be slightly more difficult to onboard new developers.

You really have a people problem more than a technical one. Some people just have to get used to new ideas slowly. I've had more than one occasion where I changed something on practically the same day an intransigent person left the company. Fortunately, it's more likely that as they start to get deeper into the git ecosystem, the git way will become more appealing. Just continue to look for opportunities to (gently) point out situations where separate repos would have been beneficial.

Answer 2

You should make every “branch” into its own repository.

While it might work like it is now (the technical details are laid out in other answers and comments) it will still introduce a lot of unnecessary complexity. Complexity means that it will be harder to onboard new colleagues, etc.