b81f56c469
When a change in Gerrit is submitted, it's possible that the submission includes other changes: 1. Open parent changes (unless the submit type is cherry-pick). 2. Open changes with the same topic (if change.submitWholeTopic in gerrit.config is set to true). Those changes with the same topic could be in different repositories or different branches. If the submission of a change introduced an issue, users often revert the change to resolve the issue, but this may cause breakages if the change had been submitted together with other changes. Usually changes that are submitted together depend on each other, so that reverting only one of the changes breaks the other changes. Hence if a submission contains multiple changes, one needs to revert all of the changes which have been submitted together. At the moment this can only be done by calling the Revert Change REST endpoint for each of the changes one by one. The new Revert by Submission REST endpoint allows to revert all changes of a submission. Since we don't have REST resources that represent submissions, the REST endpoint is offered on change level, meaning that this change and all changes that have been submitted together with this change should be reverted. It's a new REST endpoint, rather than a new flag for the existing Revert Change REST endpoint, because it needs to return a set of revert changes which can't be done from the Revert Change REST endpoint without breaking backwards compatibility (the result of the existing Revert Change REST endpoint is a single change). The only functionality added here is the ability to revert all changes with a single button. However, the changes will not be rebased on top of each other so the users may need to rebase them manually to make them submittable. The Revert by Submission REST endpoint has the following steps: 1. Check that the change for which the Revert by Submission endpoint is invoked is merged. A change that is not merged does not have a submission ID and thus we can't revert the submission of such change. 2. Find all changes that were submitted together: For this we take the submission ID of the change on which the REST endpoint was invoked and query for all changes with this submission ID. The ID of a submission is already contained in the change index and internally we can easily query changes by it (although querying changes by submission ID is not exposed to users). 3. Next we make all necessary validations such as permission validations, and ensuring the existence of all the changes. 4. Revert all changes one by one using the Revert REST endpoint. Each newly created change will have a topic that was given by the user, or a default "revert-<submission_id>-<random_string_of_size_10>". What happens when users revert the same submission twice? - Duplicate revert changes are created but they will have different unique topics. What if a submission contains a single change? - The result is similar to the result of the Revert Change REST endpoint. The only difference is that the topic of the revert change is set to 'revert-<submission-id>-<random_string_of_size_10>'. Next steps: * Optionally, when the revert submission is finished, the user should see a list of the revert changes. * When reverting a submission through the UI, the user should insert the reason for reverting this submission. * [Optional] Revert Submission action should show a preview of the changes that are going to be reverted. * Make the reverts stack on top of each other when in the same branch and in the same repository. It should always succeed since it will not rebase on top of the destination branch. * Add an option to rebase automatically on top of the destination branch. * [Optional] Add an option for interactive revert that allows the user to resolve conflicts when occur (similar to interactive rebase). * Create all reverts in a single batch. This way we also avoid multiple permissions checks. * [Google only] Consider using sharded computation, similar to submitting together multiple changes across multiple repositories. Change-Id: I7188c0d520afa669fd78309c39d44656c38259dd