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>
5ac370dbac