commit 095e20b363bee3e730abbed7489c0854c84a878b
author Edwin Kempin <ekempin@google.com> Thu Oct 15 09:40:42 2020 +0200
committer Edwin Kempin <ekempin@google.com> Thu Oct 15 09:53:50 2020 +0200
tree 69123ebde462e84ef516c4c8cfc3568b05d3ab98
parent 8e0e69b2703714d66bab9f3a4488b544d4e3cf89

Fix ISE during validation of new merge commit that was created via REST

If a revision is newly inserted, but not committed to the repository
yet, it can only be seen from the RevWalk instance that created it, but
not by newly instantiated RevWalks. When a new merge commit is created
via the create change REST endpoint we have exactly this case. This is
why change I7ec825374 passed the RevWalk to the lower layers so that
they could use it to load the merge commit. However one case was missed.
If MergeCommitStrategy.FILES_WITH_CONFLICT_RESOLUTION was configured
ChangesFiles did the comparison against the AutoMerge which is loaded
via the PatchListCache. PatchListCache opens an own RevWalk and hence
cannot see the newly created merge commit and then fails with a missing
object exception. Passing in the RevWalk into PatchListCache is not
possible. This is why for merge commits we now always do the comparison
against the destination branch (MergeCommitStrategy.ALL_CHANGED_FILES)
to find the files that need to be validated. This way PatchListCache
will never be invoked from CodeOwnerConfigValidator. Hard-coding
MergeCommitStrategy.ALL_CHANGED_FILES here is fine, since the
mergeCommitStrategy config option is only for controlling which files
should require code owner approval, but not for which files should be
validated when a new commit is created.

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