Abandoning Gitflow and GitHub in favour of Gerrit • Hacker News Board

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#131

Post by balls187 » Tue, Apr 05, 2016, 8:59 PM UTC

daigoba66 wrote: post #114

balls187 wrote: post #112

Earlier quoted context omitted.

That requires push-access. Not all team members have push access to all our source repositories.

honest question: why don't they have push access?

Prior to 2 minutes ago, I had no idea you could lock down a branch in github. We have folks working on our codebase, and the team wants to enforce code-reviews for anything that goes into our master branch. To enforce this, only a few people have push access.

This is similar to the open-source maintainer model.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#132

Post by Washuu » Tue, Apr 05, 2016, 9:27 PM UTC

1_800_UNICORN wrote: post #104

Gerrit is the wrong solution for truly agile software development. I had a client ask my team to use it, and it was a real PITA. The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. 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…

Gerrit is the reason I rarely submit MediaWiki patches back to the Wikimedia Foundation. Gerrit is a giant pain to use, has a terribly designed interface, and requires a command line plugin that makes it trivial to screw up patch reviews. I can not ask other developers on the team here to do it either since I can not justify having them hours just to learn how to not screw up using Gerrit.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#133

Post by MatmaRex » Tue, Apr 05, 2016, 9:33 PM UTC

1_800_UNICORN wrote: post #104

Gerrit is the wrong solution for truly agile software development. I had a client ask my team to use it, and it was a real PITA. The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. 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…

I use Gerrit everyday (I work on MediaWiki) and I'm not having any problems submitting multiple dependent commits. Yes, you need to rebase the newer ones if an earlier one was non-fast-forward-merged or if an earlier one is amended, but most of the time (if there are no conflicts) this is just a click on the "Rebase" button in Gerrit's interface.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#134

Post by MatmaRex » Tue, Apr 05, 2016, 9:35 PM UTC

Washuu wrote: post #132

1_800_UNICORN wrote: post #104

Gerrit is the wrong solution for truly agile software development. I had a client ask my team to use it, and it was a real PITA. The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. 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…

Gerrit is the reason I rarely submit MediaWiki patches back to the Wikimedia Foundation. Gerrit is a giant pain to use, has a terribly designed interface, and requires a command line plugin that makes it trivial to screw up patch reviews. I can not ask other developers on the team here to do it either since I can not justify having them hours just to learn how to not screw up using Gerrit.

The git-review plugin is not required, you can instead do `git push gerrit HEAD:refs/for/master` to push changes for review and use the snippets from the change's page to pull them. But it's easier to do `git review` and `git review -d` instead, and it doesn't require understanding or memorizing the weird push command. (I work on MediaWiki, by the way.)

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#135

Post by eridius » Tue, Apr 05, 2016, 9:41 PM UTC

superuser2 wrote: post #126

eridius wrote: post #82

I really want something that provides better code review than GitHub. The described code review features of Gerrit sound promising. But the article says you can't submit a series of commits for review as a unit, you only submit a single commit. Is that really true? That seems like a rather awful limitation of the system. Sometimes my changes work well as a single commit, but often, especially when doing more complica…

Phabricator[0] is awesome. Diffs (like PRs) contain several commits, but are reviewed, discussed, and "landed" as a unit with an auto-generated commit message referring to the Diff description and a link to read its history, but "master" is a linear sequence of Diffs being landed. You can also configure all kinds of rules like "X person must sign off on any changes to this file" or "do not merge code to master unless…

When you say a linear sequence of Diffs being landed, do you mean it commits squashed merges, or does it create actual merges (so the history of master includes all the commits in each Diff)?

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#136

Post by kiallmacinnes » Tue, Apr 05, 2016, 9:43 PM UTC

1_800_UNICORN wrote: post #104

Gerrit is the wrong solution for truly agile software development. I had a client ask my team to use it, and it was a real PITA. The fact that one commit = one merge is ridiculous. It encourages monolithic commits for no reason other than that the tool demands it. 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…

> 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..

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#137

Post by kibwen » Tue, Apr 05, 2016, 9:43 PM UTC

piotrkaminski wrote: post #85

eridius wrote: post #82

I really want something that provides better code review than GitHub. The described code review features of Gerrit sound promising. But the article says you can't submit a series of commits for review as a unit, you only submit a single commit. Is that really true? That seems like a rather awful limitation of the system. Sometimes my changes work well as a single commit, but often, especially when doing more complica…

You might want to check out https://reviewable.io . It has most (if not all) of the goodness of Gerrit, but is trivial to set up (SaaS) and integrates smoothly with GitHub. Every PR becomes a review and gets automatically updated whenever you push to the branch. Disclosure: I'm the founder.

Worth noting that Servo uses Reviewable, if someone's looking for an example of its use in a large, active project with many contributors: https://github.com/servo/servo/pulls

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#138

Post by kiallmacinnes » Tue, Apr 05, 2016, 9:50 PM UTC

xori wrote: post #77

I don't really see what's different. Both github and gerrit have voting and you're still creating a pull request like in github. The only difference is that this pull request is restricted to a single commit. Not very flexible, I see a lot of churn of invalid pull requests with this design if they aren't allowed to grow into complete features..

> Not very flexible, I see a lot of churn of invalid pull requests with this design if they aren't allowed to grow into complete features..

Actually, Gerrit really encourages growing a patchset ("pull request") into a complete feature. It allows you update your change over and over, addressing review comments as they come in.

Once done, you have a clean "Add support for use of XYZ by ABC" commit - and not a pile of half baked commits - I cringe when I see things like this: "Add framework for XYZ", "Define Config for XYZ", "Correct typos", "Add tests", "Rework XYZ to be standards compliant", "Correct typos", "Fix tests"

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#139

Post by chadnickbok » Tue, Apr 05, 2016, 10:22 PM UTC

_jb wrote: post #17

chadnickbok wrote: post #2

The process might seem more complex initially but think of it like this: If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing. In addition, the new GitHub code review tools addr…

This is not the only argument in this piece — I'd even argue that it's a minor one. It hardly makes sense to discredit the author and this article based on this GitHub misconception.

My main point here is that on GitHub, making a pull request is super easy. There's even a cool pop-up if you visit the main page of a repo after pushing to a branch that asks if you'd like to make a pull request.

Saying that this is somehow more complex than updating a single commit and learning a whole new tool doesn't change that if you want to convince me, you at least need to correctly identify what's going wrong.

Perhaps if the author had specifically called out their perceived failings of the very latest GitHub pull request changes I'd have given the article more time. But unfortunately the justification given for switching was really shallow.

Re: Abandoning Gitflow and GitHub in favour of Gerrit

#140

Post by chadnickbok » Tue, Apr 05, 2016, 10:25 PM UTC

ssmoot wrote: post #50

chadnickbok wrote: post #2

The process might seem more complex initially but think of it like this: If you add a new member to your team, they would have to fork the repositories on GitHub, clone them locally, make the changes, push to their own fork and then create the pull request Annndddd we're done - its easy to make a pull request from a branch; this person has no idea what they're doing. In addition, the new GitHub code review tools addr…

Github isn't exactly a utopia of UX. Yesterday I was looking for a way to refresh an old fork with upstream. I'm pretty sure there was a button for this at one point. I looked. Couldn't find it. So instead I had to: $ cd ~/src $ mkdir github $ cd github $ git clone myfork $ cd myfork $ git remote add up upstream $ git pull up master $ git push origin master Or something like that. I think I got lost somewhere along t…

That's really great point, and something I'd love GitHub to put some more time into.

But it's not the argument made by the author :-/