tree 1189eae4b04ae17bb167a443a79f3ccc82e0260f
parent fdb9c58db2fe37988cde91608ab13105b4e57fa8
author Youssef Elghareeb <ghareeb@google.com> 1626952131 +0200
committer Youssef Elghareeb <ghareeb@google.com> 1627030884 +0200

Git file diff: fix when JGit returns multiple entries for same file path

In some cases, JGit returns two {ADDED, DELETED} diff entries for the
same file path instead of a single {MODIFIED} entry. This happens, e.g.
when a file is modified between patchsets with a change in file mode
(for example converting a symlink to a regular file). In the old diff
cache world, We used to handle this case outside of the cache (see [1])
by combining the two entries into a single entry with change type =
REWRITTEN.

The implementation in the new diff cache did not handle this case: in
GitFileDiffCacheImpl, we used to collect the diff entries into a map,
keyed by file path, hence resulting in duplicate key exception in the
toMap collector.

In this change, we fix this issue
  * We keep the git_modified_files cache (the one that computes the
  modified files between two git trees) as is, allowing it to return two
  {ADDED, DELETED} ModifiedFile entries for the same file.

  * We update the modified_files cache (which wraps the
  git_modified_files cache) so that it merges ADDED/DELETED entries for
  the same file into a single REWRITE entry.

  * We update the git_file_diff cache (the one that computes the
  detailed git diff for a single file) so that it merges ADDED/DELETED
  entries for the same file into a single REWRITE entry. The logic
  is added in this cache and not in file_diff cache (the one that wraps
  the git_file_diff cache and computes the edits due to rebase) since
  the git_file_diff is requested with one key per file, so we expect it
  to return a single result value for that key.

We unignore a test that covers this case (for new diff cache) in
RevisionDiffIT to assert correctness.

We increase the version of the modified_files cache since its logic was
changed. The git_file_diff cache does not require increasing the cache
version since this issue resulted in an exception in this cache and the
entries are not yet cached.

[1] https://gerrit.googlesource.com/gerrit/+/refs/heads/master/java/com/google/gerrit/server/change/FileInfoJsonOldImpl.java#112

Change-Id: If2cab046051d96a2ce669ba573b36e44e3ec64e7