Compare view shows new code in red instead of green - left/right sides may be reversed

[Philipp0205]

Summary

When viewing a changed file in the compare editor (by double-clicking a file in the Pull Request Changed Files view), new code added in the feature branch (displayed on the right side) is highlighted in red instead of green. This is the opposite of standard diff color conventions where additions should be green and deletions should be red.

Environment

• File: PullRequestCompareEditorInput.java:186-238 (createCompareInput method)
• Related Files:
  • PullRequestCompareEditorInput.java:60-99 (constructor with label configuration)
  • PullRequest.java:41-43 (fromRef/toRef model)

Steps to Reproduce

1. Open the Pull Request List view
2. Select any pull request with modified files
3. Double-click a changed file in the Pull Request Changed Files view
4. Observe the compare editor that opens
5. Look at code that was added in the feature branch (right side)

Expected Behavior

The compare view should follow standard diff color conventions:

• Left side (main/base branch, old code): Shows as normal text
• Right side (feature branch, new code):
  • Added lines should be highlighted in GREEN
  • Deleted lines should be highlighted in RED

For example, if you added a new function in the feature branch, the function should appear with a green background on the right side.

Actual Behavior

The compare view currently shows:

• Left side (main/base branch): Shows toBranch label
• Right side (feature branch): Shows fromBranch label
• New code added in the feature branch (right side) is highlighted in RED instead of green

This creates confusion because red typically indicates deletions, not additions.

Root Cause Analysis

File: PullRequestCompareEditorInput.java:186-238

The pull request model uses:

• fromRef = source branch (feature branch with NEW code)
• toRef = target/destination branch (main/base branch with OLD code)

Current implementation (lines 194-233):

String fromCommitId = pullRequest.getFromRef().getDisplayId();  // Feature branch (NEW)
String toCommitId = pullRequest.getToRef().getDisplayId();      // Main branch (OLD)

// For MODIFIED files:
left = new RemoteFileTypedElement(client, toCommitId, ...);    // Main (OLD) on left
right = new RemoteFileTypedElement(client, fromCommitId, ...);  // Feature (NEW) on right

return new DiffNode((ITypedElement) left, (ITypedElement) right);

Eclipse's DiffNode Convention:
According to Eclipse's compare framework semantics, DiffNode(left, right) treats:

• left = "ancestor" or "before" version
• right = "current" or "after" version
• Changes in right that don't exist in left = additions (GREEN)
• Changes in left that don't exist in right = deletions (RED)

The Current Setup:

• Left = main branch (OLD)
• Right = feature branch (NEW)

This should work correctly (old on left, new on right), but the colors are inverted. This suggests one of:

1. DiffNode parameter order issue: The parameters might be in the wrong order
2. Eclipse compare configuration: There might be a missing configuration flag
3. CompareConfiguration ancestry: The framework might need explicit ancestry information

Note: The labels are set correctly (lines 73-96) showing main on left and feature on right, but the diff highlighting colors don't match.

Proposed Investigation

1. Check DiffNode constructor signature and Eclipse API documentation to verify parameter semantics
2. Review CompareConfiguration settings - may need to explicitly set ancestor/left/right roles
3. Test if swapping the parameters new DiffNode(right, left) fixes the color issue (though this would be semantically incorrect)
4. Check if Differencer.LEFT and Differencer.RIGHT constants need to be used
5. Look at EGit's own compare implementations for reference (since this plugin uses EGit/JGit)

Potential Fix Options

Option 1: Swap DiffNode parameters (if confirmed by API docs)

// If DiffNode expects (current, ancestor) instead of (ancestor, current)
return new DiffNode((ITypedElement) right, (ITypedElement) left);

Option 2: Use DiffNode with kind parameter

// Explicitly specify the diff kind
return new DiffNode(Differencer.CHANGE, (ITypedElement) left, (ITypedElement) right);

Option 3: Set CompareConfiguration ancestry

// In createCompareConfiguration method, add:
config.setProperty(CompareConfiguration.USE_OUTLINE_VIEW, Boolean.TRUE);
config.setProperty("ANCESTOR", left);  // or other ancestry configuration

Additional Notes

• The issue affects all change types: ADDED, DELETED, MODIFIED, and RENAMED
• The labels are correctly showing main/feature branch names, so the visual layout is correct - only the color coding is wrong
• This may confuse users who expect green = additions, red = deletions (universal diff convention)
• Comment overlays are correctly mapped to left/right sides (using "FROM"/"TO" file types), so this issue is isolated to diff highlighting

Acceptance Criteria

• New code added in the feature branch (right side) displays with GREEN highlighting
• Deleted code removed from the feature branch displays with RED highlighting
• The left/right labels continue to show correctly (main on left, feature on right)
• All change types work correctly: ADDED, DELETED, MODIFIED, RENAMED
• Comment overlays continue to work on both sides
• Follows Eclipse compare framework conventions
• Follows project code style (tabs, 80-char lines, EPL-2.0 header)