tree 63a7a41d04a5e3e7f97bd171d2843c6ab468cc02
parent 095d73f5682e9b6bb150bdb95035d06204d6797c
author Edwin Kempin <ekempin@google.com> 1615292949 +0100
committer Edwin Kempin <ekempin@google.com> 1615309944 +0100

Disable rename detection when computing changed files

To detect renames Git must compare file contents of deleted and added
files. Loading and comparing file contents is rather expensive and is
likely the reason why we are seeing a high latency for computing the
changed files for 1% of the changes.

By turning off the rename detection we expect that Git can do a pure
tree diff without needing to load file contents, which should be much
faster.

The rename detection in DiffFormatter is off by default, it gets turned
on only if either DiffFormatter#setDetectRenames(true) or
DiffFormatter#setPathFilter(TreeFilter.FOLLOW) is called. We rely on the
default since it's very unlikely that this default will ever change (and
if it does our rename tests will start failing).

Turning off the rename detection affects the Get Code Owner Status REST
endpoint. For renamed files it now returns 2 file code owner statuses,
one for the old path and one for the new path.

Example:

* old:

  ...
  {
    "change_type": "RENAMED",
    "old_path_status" {
      "path": "user-introduction.txt",
      "status": "INSUFFICIENT_REVIEWERS"
    },
    "new_path_status" {
      "path": "docs/user-intro.md",
      "status": "APPROVED"
    }
  }
  ...

* new:

  ...
  {
    "change_type": "ADDED",
    "new_path_status" {
      "path": "docs/user-intro.md",
      "status": "APPROVED"
    }
  },
  {
    "change_type": "DELETED",
    "old_path_status" {
      "path": "user-introduction.txt",
      "status": "INSUFFICIENT_REVIEWERS"
    }
  }
  ...

This change in behaviour requires an update in the frontend, otherwise
the code owner status icon for renamed files in the file list could be
wrong, as it would only considers the status for the new path, but not
for the old path.

The tests with renamed paths have been adapted accordingly. Since paths
are always returned in alphabetical order, the tests know which path
(new or old path) is returned first in the response and hence the
assertions can rely on this order.

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