Since I‘ve switched completely to git in 2012, all my code collaboration has been based on pull/merge requests. I‘ve never used the patch/email based approach. We tried it out today (on Sourcehut), and I‘m a bit confused on how giving detailed feedback would work 🤔 Like ”in this line, I would suggest…“ or ”I don’t understand how this part of the change works“.
@moonglum that's why Gerrit is the only correct way to use Git. Thank you, I won't be taking questions.
@bascht But I have so many 😂
@moonglum @bascht @agx I was a GitHub PR-oriented person for a very long time and then joined the openstack community where gerrit was (and still is) used. I started out hating it, mostly out of endless confusion. As I learned I still hated it.
However, when I left that community and went back to GitHub-style I desperately missed gerrit.
It is tedious and the UI is far from ideal, but it works much better than GitHub-style when either of the following are true: a) there are many contributors, b) there are many (overlapping) contributions.
Conversely gerrit is a huge pain when those things are not true.
@anticdent @moonglum @bascht @agx My workplace switched from self-hosted gerrit to GitLab. Gerrit was better for reviews, but our admins had a policy of no server-side developer branches. (never understood that)
I did find the history rewrites (via squashing) somewhat irqsome, but the team doesn't really grasp incremental changes per feature, which means larger than necessary reviews in GitLab now.
