LorenzoGatti said:
Splitting a Git repository is easy: create a new repository from a copy of established source folders, delete them nondestructively from the next revision of the original repository, and optionally import a reconstruction of old history in the new repository. Merging repositories is harder because you'd need to reconstruct history very accurately.

That is actually how I began! Having everything in Game and Renderer in the same solution but as different projects. Since they were in different folders, it was as you wrote, easy to just split them to different repos.

LorenzoGatti said:
Handling more repositories has a cost, such as running any tool or operation N times rather than one and risking to forget some repositories. Speaking from experience, I occasionally deal with a project of about 120 Git repositories and I need scripts to write scripts.

I was actually thinking of having an empty repo that would be called “Engine” which would have Renderer and Physics as submodules.
So if I were to do another kind of Game or Prototype, I would just need to pull out the “Engine” repo, and all I would need is just add the projects to the solution afterwards.

LorenzoGatti said:
Large repositories might grow to cause performance problems, but the useful mitigation strategies are keeping out unneeded files and unneeded changes, checking out only a subset of files, and compromises to reduce server effort like git-lfs and git-annex; not splitting the repository, and certainly not splitting it preemptively.

That's also one of the problem I've thought of, which is too large of a repo.
Having game, physics, renderer, utility and more projects, in 1 single repo would make it too big too fast.
Considering that I have my repos in Gitlab which only allows 10 GB compared to github 100 GB, shouldn't it prove to be better to just split my Projects to separate repos?

LorenzoGatti said:
With overly fragmented repositories units of change involve multiple repositories and therefore multiple commits, greatly complicating and degrading revision control.

This! I've already felt that by having submodules, I need to keep making commits just for the submodules.
It gets worser the longer the submodule chain becomes…

LorenzoGatti said:
Keep it simple: your subdivision of Game, Renderer, Physics and Utility is only a rough and unnecessary initial guess about the architecture of your project, and trying to guess better is mere procrastination. Instead, avoid the need to guess the right repository structure in advance by making only one repository.

I had only 1 repository. I felt I needed to split them up for better order. Which I mean, I could have changes in all kinds of places in code, game code, engine code, utility code. It's just felt too overbearing and too much for me.

LorenzoGatti said:
More specifically, you'll need major refactorings because your project is young, and refactorings would be much easier if they don't cross repository boundaries. Folders are much more lightweight than separate repositories.

I code quite modular, although I've had some refactoring done, I haven't had to make any major refactoring.
Since it's so modular, I haven't come across any major refactoring. But yes, maybe in the future…

LorenzoGatti said:
Some kinds of project lend themselves to a proliferation of structurally similar separate repositories each containing a small component of the same type: enterprise microservices that call each other but are updated individually, disparate web sites sharing some boilerplate, plugins for a certain application, and so on. On the other hand, you are developing one game, not many small ones: you'll have the privilege of considering a separate repository and new policies for your engine if the project is good enough to make a second game with the same engine.

I am actually going to make several games out of the same engine. The point of the engine is to be able to prototype a number of games. But I can see your point that, I haven't even come to the point of having making an actual game yet. So me thinking of making repositories for a second game, is of course, quite unecessary.

LorenzoGatti said:
Do you have objective reasons (e.g. constraints that require segregating servers or user access) to use more than one repository and/or any submodules?

I just want to be able to make another Game Repository and just pull 1 repository, add all the projects needed, and start developing.
It shouldn't require setups, 1 whole day or week even, to even start seeing something. Should almost be like installing a game, click install and then start playing.
Then another reason would be, Gitlab only having 10 GB per repo. I cannot judge how big the repos will become, but I would rather not deal with that later now that I already know that it might become a problem. Of course, the projects are already split to separate repos, so that's done.

Thinking that I need to “Copy” the Engine from another repository, just doesn't sit well with me.
Although, as said before, it is quite easy to split Engine to another repository then.
But that work has already been done now, so might as well keep it as well.

Before I keep writing misunderstanding oppositions, I'm not saying NO to any of the arguments of this discussion.
I appreciate the ideas you guys keep giving and please do keep giving if you do have any other ideas!
I'm just trying to get more information on what would be a good solution to keep control of everything without it being completely mish mashed.

I'm currently going with the idea of having
Game
Submodules:
-Renderer
-Physics

Separate repo
Utility (templates, functions, math). Build static library to a target directory. Game Repo then links the static library and commits the library only, and no source code.

Zansin said:
I cannot imagine 100-300 people sitting in the same repository because people would then just keep interrupting each other with commits

That can be a problem. But it can be and IS done. Typically this problem is managed with file locking and the fact that most of those people are not trying to touch the same files. This is something Perforce manages reasonably well. git by its nature as a DVCS makes locking difficult/unidiomatic. The problem is worsened when you're dealing with binary files, of course, of the type that content creators and designers would deal with, which is one reason that some devs say that git is not suited to art assets. Fortunately for us, source code can often be automatically merged. Just remember to recompile your files after you merge, and use your judgement when it comes to merge conflicts. And if you have automated tests (which in 2020 you should probably think about having if you don't have them), run those after a merge, too. ?

If you find that you're touching the same files often, that is usually a sign that your files are too big and have too many responsibilities. In legacy codebases it can be hard to split them out, but in newer, better architected codebases, refactoring ought to be less of a problem and saves everyone else time merging. Nobody wants to get stuck in a loop of “pull, merge, compile, test, pull merge, compile, test…”

Incidentally, this is one reason the number of advocates for “DevOps" ideas like having a build farm automatically merge and integrate your change for you is growing, even in the game industry (which is often behind the rest of the software industry in some ways). I've never personally worked on a project where we made that work consistently, but some people swear by it, and in a git-based workflow it becomes a lot more useful than it might with something like Perforce.

More on topic, there's certainly a school of thought that has every large component of a project be its own library, with its own (internal) release schedule, and the main “app” is just an integration point. But every time I've personally interacted with submodules it hasn't gone particularly positively and I'm not confident that the extra complexity is really worth it. I've yet to encounter many devs who know how the git submodules commands work, as well, which is a bit of a barrier to entry. If enough people on your team already know how git submodules works, then you can go with that. But there are some pitfalls…

If on the other hand you have a package manager integrated into your build system (eg. something like NuGet), I would expect that to handle things like this for you. It's also (I believe) possible to have your .gitignore ignore a folder with another git repo in it, which would be my preferred solution, because then you can interact with the sub-repo as if it were any other repo, which is more difficult with submodules. You can write a build script to populate the folders with the git repos and update them to head.

The important thing here, IMO, is to keep this setup simple so that interacting with it takes as little time as possible, everyone on your team can contribute to maintaining it (eg. force people to learn as few new things as possible), and bad module releases can be reverted quickly. If nobody understands it, then you'll quickly find that one of your team becomes “the build engineer” whose sole responsibility is maintain all this. If you're on a large team you can probably afford that, but on a small team you probably don't, and in both cases the "bus factor" is not great.

My personal feeling is that making merges trivial by aggressively segregating code within the same repository is often going to be simpler than going with a package manager or something like one, at least for small teams.