I think they don't branch code because perforce branches are horrible and merging them back to HEAD is extremely painful process for monorep.
The PDF explicitly calls out the time consuming part:
"Almost all development occurs at the “head” of the repository, not on branches. This helps identify integration problems early and minimizes the amount of merging work needed. It also makes it much easier and faster to push out security fixes."
Anyway, I feel sad that so much efforts were put on really nice VCS concepts and almost no one use them in enterprise development.
Once a month? In an averagely well run company even that may be towards the higher end.
Should your entire development strategy be based on a once a month occurrence?
Closer to once a week for me.
Example issue, note that public ones are not associated with commits: https://issuetracker.google.com/issues/122326181
If 2+ people are working on the same file which might result into a conflict, you can either: - handle the conflict as soon as you merge your branches somewhen in the future or - handle it when trying to commit your change to head
Only difference is whether you handle the conflict now, or in the future.
This whole conversation the last day or two on HN has been kind of nuts. Like everybody agrees you shouldn’t put all your code in a single file, right? Why not? It would let everyone see all of the source code in one place! But it would be huge and hard to avoid conflicts. So we split things into files. Then “trees”, etc...
Basically it sounds like googles monorepo is really a bunch of repos glued together with changes in one triggering changes in others. The difference, it seems, is that google does not get to benefit from the things OS developers like about git. It’s like google developed custom versions of GitHub, circleci, and other tools and are marketing that as a better solution (just build several billion dollar solutions to manage your monorepo!).
And even after all that, google has a bunch of separate repos for important open source or secret work.
Original file:
a = 1
Contributor X:
a = 5
Contributor Y:
a = 0
Both contributors created a pull request and submitted it. In the description they both state that the new value should be the one they put it. How would you resolve this issue in a timely fashion making sure you do not take down a service accidentally and do not slow down development too much. I intentionally gave you a very simple example but if you want we can go into rolling out new features, fixing security bugs and a lot more where such issues arise. And, no git will never be able to solve these issues.
I don't think that HN going nuts (except few zealots) and these problems come from the nature of software development in general. We have seen how Google solves these (monorepo, custom CI/CD, etc. etc.) and there are other companies solving it different ways (maybe have a branching model, using Github). People are just putting out here they experience and based on that and they level of understanding the perceived solutions.
Someone’s changes get committed first. That’s a business decision, not a code tooling one. Second pr has to adjust. Same on both mono and poly repo, just using different words.
At least branches let you have the choice, which cannot be said for branchless.
Effectively this workflow means everyone is working on the same branch and the first commit to pass review gets in. The next guy will have to rebase.
In the end one wins as you said, but the level of detail is rebasing individual commits, not merging entire branches.
So this ends up being the age-old rebase vs merge discussion.