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?