On 06/11/2018 08:31 PM, Adam Spiers wrote:
Nils Carlson <nils.carl...@ludd.ltu.se> wrote:
On 06/11/2018 03:18 PM, Adam Spiers wrote:
Nils Carlson <pyssl...@ludd.ltu.se> wrote:
Gerrit is a much more powerful tool for code-review. The workflow is
less intuitive however and has a far higher learning curve.
I disagree, but please can you clarify which version of Gerrit you
are referring to? The latest release (2.15) is an enormous leap
forwards in usability:
Feel free to disagree, this isn't based on opinion on my part but
experience, I have migrated two companies (with around 20-30
developers) to gerrit and gitlab respectively and developers have
adjusted far faster to gitlab than to gerrit. The version was
pre-2.15, 2.13 I believe, but nothing revolutionary seems to have
happened (the same patch-set based workflow).
2.15 *is* revolutionary in terms of UX because the UI was rewritten from
scratch (PolyGerrit). True, the workflow is more or less the same in
design, but how intuitive it will feel to newcomers (your original
criticism above) depends heavily on the UI.
Maybe, but I doubt it would change much. People get over the bad UI
pretty quickly (weeks,) the workflow is the hard part.
Personally I much prefer gerrit, but I have been using git since 2009
including kernel coding which puts higher requirements on skill than
most systems.
Yes, as an occasional git hacker I'm in a similar boat.
For your average developer Gerrit is a lot harder to adjust to it seems.
Yes, like I said I've heard this several times, but in the absence of
concrete details I'm really struggling to understand how this could be
more than natural inertia rather than genuinely significant practical
hurdles.
However I'm not only willing to be proven wrong but actively seeking
good explanations which *would* prove me wrong. This is because I've
already volunteered to write a document which helps people familiar with
GitHub migrate to Gerrit (intended for the OpenStack community but of
course it could be shared to a wider audience). And to do that well I
really need help understanding what people struggle with when learning
Gerrit the first time. So if you can help with that I'd be really
grateful, although don't worry if you don't have time :-)
[snipped]
but this is mostly an internal implementation detail; in practice
everyone uses a tool such as "git review" which handles all that
automatically behind scenes.
Yes, extra tooling is more or less the norm when using gerrit.
It's pretty common with GitHub too, I suspect. But even if not, I don't
see a one-off installation of a simple tool as a huge hurdle.
The difference is really on the IDE side. Eclipse has excellent
integration with gerrit these days, but most other IDEs do not.
Configuring your prefered IDE for Gerrit is not trivial in most cases.
I've seen specific tools for GitHub, but never seen anyone use them.
GitHub does not make use of specific review remotes as Gerrit does, so
there is no need for specific tooling or configuration. This is the case
with most of these tools, only Gerrit and Phabricator require/encourage
specific tooling.
Furthermore, without a helper tool or IDE which supports GitHub or
GitLab, creating a pull request or merge request requires several more
steps than with Gerrit:
0. Ensure that you have a remote fork to which you have push
access (e.g. by clicking the merge button if you don't
have push access to the target repository)
1. Push your branch to a remote fork
2. Locate that branch in the web UI
3. Click the button(s) to bring up the window in which you
draft the pull/merge request
4. Give the request a title and description
5. Submit it
Compared to the single step "type git review", I'm somewhat mystified
how anyone can claim that Gerrit is harder to get started with.
As any programmer will tell you, complexity isn't measured in number of
steps. :-) Each step above is trivial and some are in fact not needed,
and all are easy to explain.
The above however isn't correct. For an open repo on Gitlab the steps
would be as follows:
1. Push your commit to a branch of the origin repo (assuming you are
part of the project, or have push access to a set of branches which can
be granted to any signed-in user), get a URL on the command line for
creating a merge-request.
2. Click the URL, review the contents of the merge-request (if you
pushed only a single commit Gitlab will take the title and comment from
that commit), click create at the bottom.
Sure, gerrit can do this in one step without opening the we browser, but
in general most people want to look at the review before forcing others
to do so.
The negative sides of Gerrit typically outweigh the positive for
most organizations I'm afraid: - No central hosting like gitlab.com.
That's not really true. There are SaaS hosters of Gerrit, most
notably GerritForge who also offer completely free hosting for FLOSS
projects on http://gerrithub.io/ (although note that this particular
free service uses GitHub as the "back-end").
Github -> github.com Gitlab -> gitlab.com Gerrit -> many alternatives.
I.e. not central.
Why is that a problem though?
Not a problem, but a barrier to entry. It typically means yet another
sign-up and yet another account to manage. I can expect most open-source
interested developers to have a GitHub account, and many have a Gitlab
account. I also have an account on the Eclipse Gerrit instance, but that
was only because I really wanted to fix some things. Not everyone cares
that much.
- High threshold for new contributors (unusual workflow, hooks
needed. )
I keep hearing this and I just don't understand it, sorry. What's
unusual about the workflow? You create a branch, commit to it, and
then type "git review". Could it really be much simpler? And Gerrit
requires about the same amount of setup as GitHub. I already
addressed the hooks comment above. I think most people forget that
GitHub requires some setup because they already did it so many years
ago. If you have specific thoughts on this I'd love to hear them so
I can understand your viewpoint better, because like I said you are
not the only person I've heard this perspective from.
Again, not opinion. Painful experience.
What you outline is the trivial use-case, and using an additional tool
"git review". The more advanced use-cases are things like responding
to a review with new commits
With Gerrit:
1. Add / amend commits
2. Run "git review"
With GitHub or GitLab:
1. Add / amend commits
2. Run "git push", optionally with --force-with-lease, which requires
a fairly deep understanding of the implications of rewriting git
history. This is a sufficiently complicated topic that I've
blogged about it twice to try to help reduce confusion:
No need to amend force push. Developers who are getting started with git
and are really fresh can push new commits to the same branch. These can
be squashed into a single commit at merge time to keep history clean,
with a "squash and merge" button. It is of course better to do any
squashing/amending locally, but users have different skill levels and
pushing them doesn't always lead to good results.
https://blog.adamspiers.org/2015/03/24/why-and-how-to-correctly-amend-github-pull-requests/
https://blog.adamspiers.org/2017/08/16/squash-merging-and-other-problems-with-github/
or a complete re-write of the contribution.
With Gerrit:
1. Create new branch and commit the rewrite to it
2. Run "git review"
3. Abandon the old review with a comment linking to the new one.
With GitHub or GitLab:
1. Create new branch and commit the rewrite to it
2. Go through the 6 steps I listed above for submitting a new
pull/merge request
3. Abandon the old review with a comment linking to the new one.
Most users don't see it this way. They will run "git reset
<starting-commit> --hard" to get back to the original state, then create
new commits and force push. No new review necessary.
I spent a lot more time supporting users on Gerrit when doing these
things than I did Gitlab users.
I don't dispute that. But I'd love to hear more about the concrete
reasons why.
Anecdotes on offer include things like "I re-cloned the the repo and
my branch isn't there even though I pushed it".
Yeah, that's a very good point that users who are used to pushing their
changes somewhere central would need to relearn the new model. And
thanks - that's a useful point I can capture in the document I'm working
on.
But I still disagree that makes Gerrit inherently more complicated; it's
just *different*. In fact the number of steps in the processes listed
above show quite clearly that its lack of requirement to first push
changes somewhere central significantly simplifies usage.
Gerrit is more complex. If you want to think about it another way you
can consider that github and gitlab both mantain a 1-1 relationship
between local branches and branches on the server. Gerrit breaks this
with the review references. This makes it more complex for the user. Of
course, one can blindly tell the user to use extra tooling and not think
about how it works, but that isn't really constructive.
You then need to explain about refs/changes/... and that they need to
find their review there and create a branch again from the correct
change, which they first need to fetch.
There's no need to explain about refs/changes/... at all; just point
them at git review -d:
-d CHANGE, --download CHANGE
Download the contents of an existing gerrit review into a branch
Another simple one-liner.
I generally follow the philosophy of explaining things to people.
Ignorance is seldom bliss for programmers.
Gerrit is a fantastic tool, but it isn't for everyone is my conclusion.
Is *any* tool for everyone? ;-)
No, some people were quite happy in Perforce and ClearCase. Having only
a single source of truth as in ClearCase appeals to a lot of people.
For a much less kind view of Gerrit you can see this article on lwn.net
: https://lwn.net/Articles/702177/ .
Cheers,
Nils
_______________________________________________
Developers mailing list
Developers@clusterlabs.org
https://lists.clusterlabs.org/mailman/listinfo/developers
