I think this is the same issue as #24887.

It's also related to #25359 (comment), where I suggested:

I'll want to revisit the original design doc on the PR mirroring and see if I'm missing something, but right now I don't see why we can't implement 2-way syncing for commit messages. If someone edits the commit message in Gerrit, gerritbot could resolve the mismatch by editing the PR title/description to match, couldn't it?

@andybons answered that in #25359 (comment), saying "It’s not unreasonable (implementing 2-way syncing), but naturally adds complexity to the implementation." and providing detailed information on the implementation considerations.

GerritBot should be able to tell whether it has already pushed the latest GitHub PR copy to Gerrit and if so NOT re-push it when Gerrit differs.

This sounds like a simpler solution than full 2-way syncing. The benefit seems to be no need to incur the complexities of full bidirectional sync. The downside is that it can leave a GitHub PR out of sync with the Gerrit CL commit message, which can cause confusion and loss of information (e.g., if the person edits the original PR to fix a small typo, it would revert the edited Gerrit CL commit message).

@rsc It sounds like you'd want to make use of this just before merging a CL, is that right? If so, the divergence may not matter as much.

Duplicate of #24887

I agree it's confusing and annoying to have to battle with a bot.

Duping into that issue and assigning @julieqiu as a starter issue to find an solution that may not be two-way syncing, but at least won't cause the issues experienced here.