4 ms·

This looks impressive, especially how they seem to handle rebases/squashes with force push, which is a problem that pretty much all other repo managers simply i

by deng 10y ago

This looks impressive, especially how they seem to handle rebases/squashes with force push, which is a problem that pretty much all other repo managers simply ignore (except for Gerrit, but that one has other problems...).

ithkuil 10y ago
reviewable.io handles that very well too (but it's a hosted service)
- yeraydarias 10y ago
  Yay, thanks, looks amazing. Being hosted is not always a bad thing, thinking in the cost of maintenance it can deserve the price.
biehl 10y ago
Yes, that is the first thing I look for too! reviewable.io, is the only other I know of that handles this.
lima 10y ago
Phabricator handles it well thanks to its Arcanist CLI tool.
- deng 10y ago
  As I understand it, Phabricator largely avoids the problem because it is primarily patch-based and not branch-based? How would arcanist handle a force-pushed branch without simply starting a new review process?
  - lima 10y ago
    Exactly, it sidesteps the problem by decoupling branches and code review. A review request is just like a diff in a mailbox. It'd just update the diff. It's really close to the Linux kernel development model and it scales very well.
mugsie 10y ago
What do you see as the major problems with gerrit?
- robinshen 10y ago
  I checked Gerrit before and like its philosophy of enforcing atomic commits and linear history, but I do not like its way of adding special change id in commit message and push to refs/for/master. That makes new users confusing and makes it difficult to follow. So I build a gerrit gatekeeper in GitPlex to enforce same rule in pull request, that is: when you need to update a pull request, you must amend your previous commit followed by a force push. No special change-id or the magic refs/for/master will be necessary.
- deng 10y ago
  It's simply horrible to work with. It's a mystery to me how people actually review code through that cumbersome interface. Tracking a larger patch series is just painful, and I usually had to use other tools for doing the actual work. To me, Gerrit is not a tool for doing reviews, but more like a bureaucratic behemoth from project management where you have to click the right buttons and fill out the necessary forms, so that things somehow get merged. It's more like applying for a mortgage or doing taxes.
  - jeblair 10y ago
    Gerrit's current web UI is awkward, but the backend service really has the fundamentals down, and it has a first-class REST API. I used that to create Gertty which is a console UI for Gerrit that makes reading and reviewing code (in a terminal!) easy and fast.
seanpackham 10y ago
At GitLab we also think it is a great feature to bring formally into the software development workflow https://gitlab.com/gitlab-org/gitlab-ee/issues/896 https://gitlab.com/gitlab-org/gitlab-ee/issues/896

by deng 10y ago

ithkuil 10y ago

reviewable.io handles that very well too (but it's a hosted service)

yeraydarias 10y ago
Yay, thanks, looks amazing. Being hosted is not always a bad thing, thinking in the cost of maintenance it can deserve the price.

biehl 10y ago

Yes, that is the first thing I look for too! reviewable.io, is the only other I know of that handles this.

lima 10y ago

Phabricator handles it well thanks to its Arcanist CLI tool.

deng 10y ago
As I understand it, Phabricator largely avoids the problem because it is primarily patch-based and not branch-based? How would arcanist handle a force-pushed branch without simply starting a new review process?
- lima 10y ago
  Exactly, it sidesteps the problem by decoupling branches and code review. A review request is just like a diff in a mailbox. It'd just update the diff. It's really close to the Linux kernel development model and it scales very well.

mugsie 10y ago

What do you see as the major problems with gerrit?

robinshen 10y ago
I checked Gerrit before and like its philosophy of enforcing atomic commits and linear history, but I do not like its way of adding special change id in commit message and push to refs/for/master. That makes new users confusing and makes it difficult to follow. So I build a gerrit gatekeeper in GitPlex to enforce same rule in pull request, that is: when you need to update a pull request, you must amend your previous commit followed by a force push. No special change-id or the magic refs/for/master will be necessary.
deng 10y ago
It's simply horrible to work with. It's a mystery to me how people actually review code through that cumbersome interface. Tracking a larger patch series is just painful, and I usually had to use other tools for doing the actual work. To me, Gerrit is not a tool for doing reviews, but more like a bureaucratic behemoth from project management where you have to click the right buttons and fill out the necessary forms, so that things somehow get merged. It's more like applying for a mortgage or doing taxes.
- jeblair 10y ago
  Gerrit's current web UI is awkward, but the backend service really has the fundamentals down, and it has a first-class REST API. I used that to create Gertty which is a console UI for Gerrit that makes reading and reviewing code (in a terminal!) easy and fast.

seanpackham 10y ago

At GitLab we also think it is a great feature to bring formally into the software development workflow https://gitlab.com/gitlab-org/gitlab-ee/issues/896 https://gitlab.com/gitlab-org/gitlab-ee/issues/896