commit 9a6f0543501dea19623feb9730ab5ca7ff37b410
author Edwin Kempin <ekempin@google.com> Wed Jan 13 13:51:42 2021 +0100
committer Edwin Kempin <ekempin@google.com> Wed Jan 13 16:31:17 2021 +0100
tree 308ab4c1d0bc2a1da1e7bc26ea567302a989064d
parent 1f60e356ee3616f7ba898bc5a72e8a7add4c925b

Allow rebase with conflicts

So far if a change could not be rebased due to conflicts the Rebase
Change REST endpoint failed with '409 Conflict'. This change adds a new
input option that allows the rebase to succeed even if there are
conflicts. Adding this option e.g. enables third-party integrators to
implement an online editor that allows users to rebase changes and then
resolve conflicts online.

If the new option is set and there are conflicts, the rebase succeeds
and the new patch set is created, the change is set to work-in-progress,
the conflicting files contain git conflict markers and a change message
with the conflicting files is posted. In addition the returned
ChangeInfo has the 'contains_git_conflicts' field set to true so that
callers can detect that there were conflicts. This is consistent with
the same option that change Ib6bc8eedf added for the Create Change and
Create Merge Patch Set REST endpoints. The implementation follows the
example of these existing options, but some things are worth to be
pointed out:

* rebasing with conflicts only works if content merges are enabled
  (see RebaseChangeOp#setForceContentMerge(boolean)):
  - this is always true for the Rebase Change REST endpoint
  - this is not true for Rebases that are automatically done on submit
  - the forceContentMerge decides which Merger is used to create the
    merge commit, if forceContentMerge is true, the created Merger is a
    ResolveMerger, which is the Merger that allows to merge with
    conflicts
* to convey the information about which files have conflicts we need to
  create a CodeReviewCommit rather than a RevCommit:
  - to create a CodeReviewCommit we need a CodeReviewRevWalk, this rev
    walk must be set on the BatchUpdate that executes the rebase
    operation (the rebase operation can then cast the RevWalk from the
    context to CodeReviewRevWalk, this is a bit error prone, but a
    pattern that we already use, e.g. in SubmitStrategyOp)
  - when the rebase operation is used from a submit strategy the RevWalk
    in the context already was a CodeReviewRevWalk, for the Rebase
    Change REST endpoint we are setting it now
* the 'contains_git_conflicts' field in ChangeInfo is only populated in
  the ChangeInfo that is returned by the Rebase Change REST endpoint,
  but not when then ChangeInfo is newly retrieved from the server (this
  is because the information whether the change has conflicts is not
  persisted, which is the same as for the other REST endpoints that
  support this field)
* in the Java API we had to add a new method that exposes the ChangeInfo
  that is returned by the Rebase Change REST endpoint
  (RevisionApi#rebaseAsInfo(RebaseInput)), this follows the example of
  the Changes#createAsInfo(ChangeInput) method

Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: Ie26fbd03b890dd197509ca1fc6133b3ea7151916