commit 5ac370dbac01ea1a6d5106db2f92688c5b13dd00
author Edwin Kempin <ekempin@google.com> Fri Oct 05 13:39:34 2018 +0200
committer Edwin Kempin <ekempin@google.com> Wed Oct 10 11:26:00 2018 +0200
tree 1ae3416586911ad0ff0a6e98dd1eb9cb0278b97e
parent 1a0af673419efe8435d4323773ee59a50c49b196

Support allow_conflicts option in cherry-pick input

If the allow_conflicts option in the cherry-pick input is set the
cherry-pick also succeeds if there are conflicts. If there are conflicts
the file contents of the created change contain git conflict markers to
indicate the conflicts. Callers can find out if there were conflicts by
checking the contains_git_conflicts field in the CherryPickChangeInfo
that is returned by the cherry-pick REST endpoints.

The cherry-pick REST endpoints now return CherryPickChangeInfo instead
of ChangeInfo to carry the contains_git_conflicts field back to the
caller. This is backwards compatible since CherryPickChangeInfo extends
ChangeInfo and only adds contains_git_conflicts as an additional field.

A draw-back of this solution is that we must adapt ChangeJson to be able
to populate a CherryPickChangeInfo instance which makes the ChangeJson
API a little more complicated.

Alternatively I considered the following solutions to let the caller
know if there were conflicts during the cherry-pick:

1. Extend ChangeInfo:
   Add the contains_git_conflicts field directly in ChangeInfo. This
   would work, but it's bad to have a field in ChangeInfo which is
   specific to one REST endpoint and otherwise unused. This can be very
   confusing to users, e.g. the field is set when the ChangeInfo is
   returned from the cherry-pick REST endpoint, but when the same change
   is retrieved again (e.g. via the change details REST endpoint) it's
   not set, although the change still contains the same conflicts.
2. Return a CherryPickResultInfo from the cherry-pick REST endpoint
   which contains ChangeInfo and the contains_git_conflicts field. This
   would break clients that expect a ChangeInfo to be returned. We could
   return CherryPickResultInfo only when allow_conflicts is specified
   but it's confusing that the response type depends on the options that
   are set in the input.
3. Return a CherryPickChangeInfo (as in the chosen solution) but use
   ChangeJson to populate a ChangeInfo and then copy all its fields into
   a CherryPickChangeInfo instance. For this we would need to have some
   code that copies over the many ChangeInfo fields which we have to
   adapt each time a ChangeInfo field is added, removed or changed.
   There is a risk that we forget to dapt this copy code. It would be
   possible to use reflection to do the copying but some fields require
   deep defensive copies which makes an reflection-based approach more
   difficult.

For the extension API I had to add a new cherryPick method that returns
CherryPickChangeInfo since the existing cherryPick method returns
ChangeApi and hence cannot be extended to return additional fields.

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