Hacker News new | ask | show | jobs
by exDM69 4421 days ago
Just to give a second opinion... I do not like working with Gerrit (I work with Android, for a HW vendor). In particular, reviewing one patch at a time becomes painful very quickly. Especially for complex features that end up having many changesets, because it's difficult to review what was changed in the newest changeset.

I would prefer having a branch to review rather than a single patch. When there are fixes, add a new commit to the branch and squash/rebase before merging to master. This way it would be easier to see what is happening during the development of a more complex feature with many rounds of review and fixing.

(note: we might not be using the latest version of Gerrit and our version control practices could be better)

1 comments

On the third hand: while pushing a line of commits to Gerrit does create separate reviews for each, there's nothing stopping you from pulling the entire branch down and looking at it as a whole, as well as being able to make sure each individual commit makes some level of sense. I especially like how Gerrit+Jenkins lets you build every revision. I don't like the way that GitHub and similar tools (thinking specifically of Stash) make it more difficult to look at the individual commits.

I'm also a fan of Gerrit having to option to enforce fast-forwards, something GitHub doesn't allow: it will always make a merge commit, even if there's only one commit and its parent is HEAD of the branch being merged to.