x/build/cmd/gerritbot: Gerrit edits are immediately overwritten by older GitHub commits

[bradfitz]

I tried to edit a commit message on Gerrit, but gopherbot fought me and reverted it:

https://go-review.googlesource.com/c/sys/+/107302
https://go-review.googlesource.com/c/sys/+/107302/2..3

I'd only expect it to be reverted if there was a new patchset on GitHub's side.

/cc @andybons

[andybons]

Yep. A consequence of the one-way nature of GerritBot v0.

[FiloSottile]

More fighting. https://go-review.googlesource.com/c/crypto/+/110796

I think the 80/20 way to fix this would be to implement Gerrit → GitHub for the commit message, and just send a warning in a comment when a new patchset is uploaded. We can see if that causes rollbacks.

[andybons]

That's fine with me. The issue is one of complexity. Synchronization of Gerrit/GitHub/Maintner is a non-trivial part of the tool. Something to watch out for.

[rsc]

@bradfitz's original report and my #28713, which was de-dup'ed into this issue, are NOT about what @andybons retitled this as.

GerritBot v0 could be one-way and still NOT overwrite Gerrit changes made after the latest GitHub PR was pushed to Gerrit. That should be trivial to do: before re-pushing something from GitHub to Gerrit, see if that exact commit has already been pushed as an earlier patch set. If so, don't push it again. Everything is still one-way from GitHub to Gerrit, but local Gerrit changes would no longer be immediately overwritten.

In addition to the example Brad gave from April and the example I gave from a few days ago, here's one I stumbled over from July: https://golang.org/cl/124775.

I retitled this to make clear that the issue here is NOT about two-way sync, just about one-way sync not being quite so insistent on overwriting new Gerrit commits with old GitHub commits.