It's essentially rewriting history. As a contributor it's nice to know a commit went in exactly as you wrote it, which is not the case when the commit hash changes.

Git is powerful because it was written with the ability to merge trees. The cherry pick workflow is throwing all of that in the trash. Why not use SVN at that point?

Because of cherry picking in Gerrit, dependent patches are a nightmare to maintain. Say patch c depends on b, which depends on a. Now say that patch c requires a change that merged into master. Because you can't merge into your development branch, you have to rebase c AND b AND a. This really pissed of the owners of b and a because it shows up as a new changset and wipes out votes. God forbid you depend on two different patches that each have separate dependencies.

You can use the merge commit to add the review information if you want. Then you don't have to molest the code change commit.

One nice thing about Git is it lets you choose your workflow.

Our general workflow for the Go project is to review single commits, and sometimes do major new work in feature branches. When we submit a single change we cherry-pick. When we merge trees, we create a merge commit.

We don't write commits that depend on other pending work. That's overly complicated (IMO) even if you always use merge commits.

It's not complicated at all if you use merge commits. That's exactly what you are doing with a feature branch. Failing to realize merge commits are useful is what makes them complicated.

It doesn't matter what the mechanism is; writing code that depends on code that changes is more complex than simply not doing that.

You can't "simply not do that" if you're project is fast moving. That's essentially the "you're holding it wrong" defense for a terrible design flaw.

Imagine you are developing a plugin framework for something and would like to develop a reference plugin at the same time to flesh out the API. Neither belongs as part of the same change but the plugin certainly depends on the framework. This is basically impossible in Gerrit because of the awful way dependencies work. The only way it can work is with a feature branch, which is basically giving up on Gerrit anyway and using git in the way it was intended.

Gerrit ultimately becomes a choke point on the throughout a given project can have unless you have an extremely small set of contributors that can coordinate well (i.e. Not a large open source project). Maybe this isn't a problem for Go since there is a high barrier to entry for contributors, but it's something to keep in mind.

The Go project is sufficiently modular that this isn't an issue for us.

Didn't you say that you used feature branches? If so, that was a case where Gerrit failed and you had to use git in an almost normal way.

How is that Gerrit failing? Gerrit is designed to support all kinds of workflows, just like Git. As far as I can tell, we're using our various tools the way they were intended. Just because it doesn't line up with your exact view on how Git should be used, doesn't mean we're doing something wrong (or "insane").

This is a boring conversation.

If it's boring, why were you trying to defend such a suboptimal use of git?

The "don't rewrite history" train has left a _long_ time ago, when mercurial and monotone were still relevant.