| > The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. That's one way of looking at it. Another is, it encourages small self contained units that build to become a full fledged feature. > It's unrealistic to ask someone to code review multiple commits per feature, and if you tie in your CI it doesn't make any sense to run your build over and over again for a single feature either. Re CI - Every change to the code should be verified by CI. With gerrit, you can choose to execute the tests for every patchset as its uploaded, or only once it's received a number of reviews or been approved. > The patchsets DO allow you to see the history of a code review if you have to make changes, but I'd much rather see that live in my git history rather than in Gerrit's history. I actually kind of agree here, if you migrate away from Gerrit, keeping the review history is hard. Though, every revision of every patchset is actually stored in Git, as are a history of the votes (in the form of a `git note` attached to the commit). > Nowhere does the author mention how painful it is if you finish a feature, are waiting for a code review, but have to start the next feature using the code you just wrote. Maybe I'm missing some magical feature in Gerrit that makes this easy, but if you push multiple dependent commits to Gerrit, and one of the early ones gets merged, all of the later ones now have to be rebased because Gerrit created a merge commit in the middle. This really sounds like your Gerrit admins just chose some bad config options.. |