The Gerrit code review iceberg
19 points by FedericoSchonborn
19 points by FedericoSchonborn
Though an "iceberg" of languished code reviews, Gerrit's per-commit review model is why they will be able to move forward sanely. Rebase-push-patch-set is what they will need. Oh boy do I cringe to think of the convoluted manual workflows popular git forges would force-push (pun intended) on anyone trying to keep this kind of thing alive in those forges.
I also think that scrubbing through partially completed projects like this is a good activity for an open source community to go through periodically. Our time and energy and focus are always limited, and it's so easy for things to languish because we couldn't all get together for the sustained push required to get more complex stuff completely delivered -- but the second best time is always now! Sometimes a new set of eyes on an old project can be the spark that gets things over the line.
When I take over PRs from another author, I push additional commits when requested by the reviewer. I don't think that's too complicated.
Correct; that's the simple case. However, a slow-burn development workflow inevitably has to integrate changes from at least one other branch (typically latest develop or master), without destroying change history, nor review history. Gerrit makes this trivial.
edit: It's a bit difficult to convey exactly why I'm so rah-rah Gerrit, because it is a matter of day-to-day experience of
... to name a few key ones.
I push additional commits when requested by the reviewer.
This is the part that's the problem. For more: https://gist.github.com/thoughtpolice/9c45287550a56b2047c6311fbadebed2
Oh boy do I cringe to think of the convoluted manual workflows popular git forges would force-push (pun intended) on anyone trying to keep this kind of thing alive in those forges.
There's tools that can help, but they can only go so far, at least with GitHub there's some hard limits.