|
> if you push multiple dependent commits to Gerrit, and one of the early ones gets merged, all of the later ones now have to be rebased because Gerrit created a merge commit in the middle. Someone didn't spend time configuring gerrit or configured it wrong for your use cases. You can solve this in one of two ways: you either fast-forward when possible (gerrit can attempt a trivial rebase) or you commit a change set, create your own merge commit, and then your early ones won't get merged until your last commit. Gerrit will wait to merge the early commits (and vice versa if dependant commits are ready) until everything is good, then merge them all in one shot. I used gerrit heavily for a few years (and still do, passively, with golang and other public google projects) and I miss it dearly. Sure it's not perfect, but I'd take it over the github fork/make pull requests model any day of the week. It does not encourage monolithic commits. You need developers to understand what they are doing, care about commit history and be disciplined during development. In my experience, developers who just want to hack shit together, cut corners and love squashing commits or throwing away history hate gerrit. Developers who care love it. It's definitely possible and easy to produce Agile software. Like anything else, you should use the right tool for the right job. If you're not willing to suck it up and learn something new, then it's not going to have a chance to be the right tool. |
I think the OP's point was that Garret hides a lot of features that are built into git and then attempts to paper over that fact by re-implemting those features within its own system.
In your first paragraph, you defend Garrit's rebasing procedure and then you implicitly accuse the OP of not being willing to "suck it up and learn something new".
Why should we learn a new tool that makes (arguably poor) attempts at re-implementing the features of a tool that we already know and love?