3 ms·
Still, that's a limitation of the specific tools and the way you're using them, not a fundamental problem with monolithic repositories. You're running into pro
by teraflop 11y ago
Still, that's a limitation of the specific tools and the way you're using them, not a fundamental problem with monolithic repositories.
You're running into problems because you have multiple people all trying to push to the same branch, and Git errs on the side of extreme caution rather than creating a merge that you didn't specifically request. If you use merge requests instead, as supported by Github/Gitlab, you don't get blocked by other people's commits.
(Actual merge conflicts are an orthogonal problem. They'll happen whenever you have multiple people editing the same code, regardless of what VCS you use or how it's organized.)
The Linux kernel example is a bit of a tricky one. Yes, kernel.org hosts a lot of repos, but they're all different versions of the same codebase. They have a common commit ancestry, and commits get merged from one to another. So they're not really separate modules in the sense that we're talking about; they're more like namespaces that each contain a set of branches.
- Confusion 11y agoI guess it comes down to organisational style. Using merge requests requires some benevolent dictator (poor sod?) to perform the merges. For us, if your commit is approved in Gerrit, it's your task to merge it. If some other commit was merged in between, you have to rebase, possibly solving merge conflicts. So guess that with a monolithic repo, that wouldn't scale, but it could be made to scale by appointing someone to perform the merge requests. I'm not sure I would like to be that person...
- Mathiasdm 11y agoI helped set up such a system for a few hundred developers. We had an 'automated Linus Torvalds', which did the merge, and aborted whenever a file was changed on both sides of the merge. In the good case (almost every time), there were no conflicts, and the merge went fine (we had unittests, builds and regression tests as extra checks in our CI system). In the bad case, the developer request was rejected and the developer was told to rebase or merge his code on his own, so the merge issues would be handled.