3 ms·
Us, for instance.[0,2] But sure enough, we definitely weren't the first to go down this path. Facebook was using (or developing the tech for) server-side rebas
by bostik 8y ago
Us, for instance.[0,2]
But sure enough, we definitely weren't the first to go down this path. Facebook was using (or developing the tech for) server-side rebasing in 2015.[1] Gitlab provides native server-side rebase functionality, likely inspired by various parties already having developed tools to do the same.
These aren't new ideas. But handling them at the scale where you land hundreds or even thousands of commits a day to a repo and require the ability to deploy at will, that's where engineering comes into play.
0: https://smarketshq.com/marge-bot-for-gitlab-keeps-master-always-green-6070e9d248df https://smarketshq.com/marge-bot-for-gitlab-keeps-master-alw...
1: https://softwareengineering.stackexchange.com/questions/278713/why-server-side-repository-merge-is-a-terrible-idea-in-git https://softwareengineering.stackexchange.com/questions/2787...
2: https://github.com/smarkets/marge-bot https://github.com/smarkets/marge-bot
- lozenge 8y agoYours seems identical to Bors, just for Gitlab instead of GitHub? That isn't really what's described in the OP.
- bostik 8y agoYup, pretty much. I was mostly answering the parent, who in turn was questioning the lack of novelty. The concept of an evergreen master with testing done in branches, followed by automated merges/rebases is not special. Quite a few companies have been doing it for years, it's the off-the-shelf tooling and subsequent publicity that haven't necessarily been around as long. As for OP's material? The automated conflict resolution via reordering to optimise parallelism - that certainly feels novel.