Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/build/cmd/gerritbot: bot insists on overwriting gerrit-side modifications #28713

Closed
rsc opened this issue Nov 10, 2018 · 2 comments
Closed

x/build/cmd/gerritbot: bot insists on overwriting gerrit-side modifications #28713

rsc opened this issue Nov 10, 2018 · 2 comments
Assignees
Milestone

Comments

@rsc
Copy link
Contributor

@rsc rsc commented Nov 10, 2018

In https://go-review.googlesource.com/c/blog/+/143544 I tried to update the commit message myself instead of sending the change back for another PR round, and GerritBot basically instantaneously reverted my edits, by re-pushing the copy from GitHub.

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.

@rsc rsc added this to the Unreleased milestone Nov 10, 2018
@dmitshur

This comment has been minimized.

Copy link
Member

@dmitshur dmitshur commented Nov 10, 2018

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.

@andybons

This comment has been minimized.

Copy link
Member

@andybons andybons commented Nov 12, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.