This is sad. In my experience, Gerrit is a much better code review system than Gitlab merge requests. But it is different from what people are used to.
I agree though. I think the most important thing in a code review system is inline comments in the diff itself, and that’s something you get from Gerrit, Phabricator (Differential), etc. It encourages people to discuss the particulars of of a diff. Merge approval can be made contingent on resolving minor issues within a diff. Diffs are also approved on a per-diff basis, and it’s less typical to merge a stack of diffs.
I think the pull request / merge request makes sense with the “trusted lieutenants” development model that the Linux kernel uses, but for other projects you would be more likely to want a work flow where someone submits a single commit/diff and then someone approves it (after comments).
When I review PRs on services like GitHub I very often think, “This should be several different reviews” and the discussion thread in a PR is often not a high-quality discussion. I don’t use GitLab as much but my experience is that it has the same problems. What I would love is to review a stack of commits and approve / make comments on the commits individually.
(For those reading: Mondrian -> Rietveld -> Gettit, and also Mondrian -> Critique. Mondrian and Critique are internal tools at Google. Phabricator originated at Facebook which has a lot of ex-Google engineers on staff.)
(there's some old discussion on there, random example)
Designers and even many developers found it essentially impossible to use and the developers who were reasonably comfortable with it spent way too much time assisting others in attempting to use it.
(fwiw I found myself somewhere in the middle - I like the model and understood the ideas but also found it annoying to work with in practice)
However, since my interests vary considerably, and therefore I dabble with lots of different tools, the difficult-to-learn tools never get enough traction in my limited human memory to get me to the easy-to-use stage.
If a community doesn't want to engage occasional users, it's probably fine (maybe even desirable) to have a higher barrier to entry to make daily use really fast.
If a community benefits meaningfully from occasional users, a high learning barrier may not be a good thing.
I dont really think the choices that they did make that work, are really any better in optimized daily use than intuitive choices would have been.
(Yes probably much of this is fixed)
Is there a project out there that originally used something like Gerrit, Phabricator, Reviewboard, or a mailing list that moved to Gitlab or Github where the number of contributions increased after the change?
$ git checkout -b my-feature-branch
$ emacs ... <edit edit edit>
$ git add -i ...
$ git commit
$ git review
read reviews, edit
$ git add -i ...
$ git commit --amend
$ git review # push new change revisions
[1] https://docs.openstack.org/infra/git-review/ [2] https://www.mediawiki.org/wiki/Gerrit/git-review
Possibility to send out a PR for review using just a push (change message in commit, push to refs/for/master%r=foo).
Snappy and compact code review experience (no space wasted for whitespace, avatars, pretty buttons). Full coverage with keyboard shortcuts.
Powerful review rule system based in Prolog, allowing for things like code owners, experimental subdirectories without the need for review, etc.
was forced to use Gerrit by a client. I could never get the hang of this, I like to do frequent commits on short lived branches and using vanilla git. I never wanted any more features other than a nice UI to encourage people to review.
With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. Alternately, if you just keep adding commits, then the final branch that gets merged (unless you squash) has all the in-progress work which pollutes the repo's history.
Gerrit also has a finer grained permission model, but I don't care as much about that.
Gerrit definitely expects the user to understand how git works conceptually a bit more than Github/lab.
That's not quite true. Gitlab lets you compare any two "versions" of the force pushed branch.
Seriously I'll pay for those couple of KiB of space, just keep it around. (at least until the PR is closed)
Just update your change set, then push to refs/for/<branch_name> again.
My memory was you had to force push your working branch to refs/for. Thank you for the correction.
I've actually setup and run instances of it as two companies, but as I say, it's been a while.
I felt I needed to correct you because with Gerrit you reserve the concept of force pushing for exceptional cases, which I think is the correct mental model. Force pushing should not be done frivolously.
So what happens when you push to changes/nnnn/12 when revision 11 hasn’t been created?
I'm not sure about Gitlab, but Github has recently added a feature where you can view the diff between the old branch head and new one. But, as far as I'm aware, there's no way to check out the previous branch head from the repo due to a lack of a remote branch pointing to it.
At least git itself provides a range-diff command that allows you do see a diff between the commits between two versions of a given branch.
I was excited to finally bring in git as we start ramping down on a legacy project onto something new. Then I started thinking about the developers that have never touched git and I need to support. I looked at the tools available and what workflows they dictate. Then there's the drive to do something similar to the rest of the company, autonomy only goes so far without a good reason.
Fuck me. I'm going to pick GitLab and hate it.