Perhaps it would also be useful to restrict who can push directly to master? Or perhaps pushes to it should require a "yes I really am trying to push master" confirmation or flag.

Pushing to master is already strictly limited (and I plan to make it opt in also for the people who can). This mistaken merge happened via a regular Gerrit review.

For #43147, our attempted merge actually wound up like a cherry-pick of all changes from master on to dev.regabi, with just a single parent (so it wasn't even a merge commit). We believe this is what happened:

$ git change dev.regabi
$ git merge master
# Fix merge conflicts, add files
$ git commit
git-codereview: cannot commit on dev.regabi branch
$ git merge --continue
git-codereview: cannot commit on dev.regabi branch
$ git change m
$ git mail

We believe the git change m at the end got confused by the in-progress uncommitted merge state and wound up creating a cherry-pick-like commit on branch m with that state.

At a minimum, git change X should refuse to do anything if you're in a pending merge state.

Maybe even allowing the git change dev.regabi was a problem, since it wasn't going to allow commits on that. Perhaps it should either just allow committing to that name (personally I find it really annoying that it restricts what branch names you can use), or it should disallow changing to names that can't be committed to. The latter would probably require a flag to git change to say "make branch X that's for upstream branch Y", which may be a good thing to have anyway.

Change https://golang.org/cl/279772 mentions this issue: git-codereview: new sync-branch and related fixes