Skip to content

[Feature Proposal] Diff: Display Moved lines (ala git diff --color-moved)

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

Diff viewer has ability to detect and display moved lines of code

Problem to solve

Some changes are conceptually very small, but generate large diffs - for instance, a change that simply moves the location of a single long function, with no code changes. Conceptually, the change is simple: "Moved lines XXX-YYY to UUU-VVV". But for a 100-line function, this will generate 200 lines of diffs - 100 removal lines, and 100 addition lines.

For someone having to review such a change, there is no easy way to tell if any of the lines have been altered or not - generally, the reviewer has to either:

  • assume the lines are unchanged
  • laboriously manually review all moved lines
  • resort to a third party tool, that allows display of moved chunks of code

Proposal

We can leverage an existing solution to this problem: git's support for this feature via it's git diff --color-moved option:

https://git-scm.com/docs/git-diff#Documentation/git-diff.txt-code--color-movedltmodegtcode

We can use this feature as either an inspiration (ie, display moved lines via different colorations) or actual backend (use git's implementation, either via subprocess call of a git binary, or by using the source code - licenses allowing).

The most basic implementation could be as simple as --color-moved - ie, a different color scheme (with perhaps a legend showing how to interpret them).

The next (or alternative) level of implementation might be to add text describing the type of diff block ("Moved Code", "New Lines", "Removed Lines"), with perhaps a link to the corresponding old/new block for "Moved Code".

More UI fanciness could be designed around this feature (ie, similar to those used by SemanticDiff - https://semanticdiff.com/)... though many users might prefer a faster implementation / release to lots of custom UI niceties (myself included).

Most likely, this feature would be implemented as an optional additional way to view diffs, due to the additional complexity, potential changes to the UI, and familiarity of users with "standard" diffs.

However, it's possible that if the the underlying algorithm was reliable / performant enough, and the UI integration was fairly seamless and unobtrusive, then it could be added as an "always on" feature for all diffs.

Related Issues

Intended users

This would be usable by anyone reviewing code diffs / merge requests, including Developers and Managers. It has the potential to both speed up code reviews and improve code review quality. A one-line accidental typo while moving a large function could be easily detected.

The roles most likely to benefit directly would be those heavily involve in editing and reviewing code, or configuration stored as text in a repository, such as:

Feature Usage Metrics

If this feature is implemented as an optional diff "mode" or "view", then it would be fairly easy to track how often users opt to use this mode.

If it's an "always on" feature, or if you simply wanted more detailed metrics, you could track:

  • If UI features specific to this feature are added (ie, links to corresponding chunks of text, or buttons to expand the "other side of the move" in-place) usage of these could be tracked
  • You could keep statistics on how often moved lines were detected, and what percentage of the diff lines were detected as moves within a changeset, or how often changesets had a move-percentage that exceeded some threshold (say, > 50% of the altered lines were classified as moves).

Does this feature require an audit event?

No - a diff view in itself results in no changes, and happens too frequently to be of interest to auditors.

Edited by 🤖 GitLab Bot 🤖