commit 62e2b1ec72ea3ebed939a21dbde213d2c1add552
author Edwin Kempin <ekempin@google.com> Tue Mar 16 13:07:03 2021 +0100
committer Edwin Kempin <ekempin@google.com> Wed Mar 17 13:56:38 2021 +0100
tree dc629317cf407ea6c63c85cedc29b4518a794c94
parent b03becb79d5cc211ef1f70280dca69b62795abf8

Avoid computing changed files for automerge commits using PatchListCache

ChangeFiles has 2 methods to compute changed files:

1. computeByComparingAgainstAutoMerge:
   This method uses the PatchListCache for computing the changed files,
   but PatchListCache can be slow (> 30s). Once the result is cached any
   further access is fast.
   The primary reason for using PatchListCache was that it takes care of
   creating the auto merge commit.

2. computeByComparingAgainstFirstParent:
   This method uses DiffFormatter (without rename detection) for
   computing the changed files. This seems to be fast also for changes
   that touch many files.

This change drops the usage of PatchListCache and uses DiffFormatter
also for case 1. This means that ChangedFiles now needs to take care of
creating the auto merge commit, but it's only a matter of invoking
AutoMerger.

Alternatively we could have used the new file diff cache for case 1, but
we do not because:
- This cache is very new and we do not know for sure that it's always
  fast (e.g. it may do some kind of rename detection).
- We cannot use the new file diff cache for case 2 as in this case we
  must use the provided RevWalk for loading commits and we cannot pass the
  RevWalk into the file diff cache. Hence for case 2 we would need to
  continue using DiffFormatter. Then we can also use this existing code
  for case 1 and avoid having a differentiation between computing
  changed files against first parent and against auto merge.

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