version control – Disadvantages for having completely different codebases in different git branches

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?