New Code Coverage skewed by pure file moves (src → src/main/java) misclassified as new code

SonarQube Server / Community Build
,
1

We’re using SonarQube Developer Edition v2026.4.1 (126914).

We use the Reference branch New Code definition, pointed at a branch fixed to the beginning of the year, so “new code” = everything changed since then.

Over the year we moved the source directory of several Java modules from src to src/main/java. Each move is a single commit containing a paired delete (old path) + add (new path) — a clean rename with no content changes.

Git itself detects these as clean renames (visible via git log --follow, or blame with rename/copy detection), but SonarQube does not recognize the move — it treats the moved files entirely as new code. Since none of that new code has fresh test coverage attached, our New Code Coverage metric for those modules drops sharply — even though not a single line actually changed.

Questions

  1. Is there a supported way to make the New Code calculation recognize a same-commit delete+add of identical content as a move, instead of counting it as new code?
  2. Is this a known limitation?
  3. Any recommended workarounds for large-scale directory restructurings mid-year that others have used successfully?

Any pointers or war stories appreciated, this is currently blocking accurate coverage tracking for the modules we’ve already moved.

2

Hey @bben, unfortunately, detection of moved files is not supported when using the reference branch new code definition. Other new code definitions go through the history of commits and therefore can detect moved files as reported by git (for example, in PR analysis this is the case), but the reference branch mechanism simply compares lines between the latest version of both branches.

Other discussions in the past have concluded that this behavior is expected and this limitation is accepted, so I wouldn’t count on it being re-visited soon.

There’s no great workaround, but you could adjust your New Code baseline around the refactor (for example by using Previous version or by resetting your reference branch after the move), or to temporarily relax coverage-on-new-code conditions while you complete the restructuring.