eclipse-platform / eclipse-platform/eclipse.platform
UnifiedDiff for staged files with Git
- Dominant language
- Java
- Stars
- 165
- Forks
- 174
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 22
Description
The UnifiedDiff compares currently against a file from the workspace. As soon as a file is staged, the comparison falls back to the old compare editor as now two Git states (index vs head) are compared.
The fallback is decided in CompareUIPlugin.prepareUnifiedDiff(...) . The unified diff needs a workspace file ( IFileEditorInput ) to overlay onto:
````
if (leftEditorInput instanceof IFileEditorInput) { // working-tree side
return new UnifiedDiffSource(..., UnifiedDiffMode.REVERT_MODE, ...);
}
if (rightEditorInput instanceof IFileEditorInput) {
return new UnifiedDiffSource(..., UnifiedDiffMode.OVERLAY_READ_ONLY_MODE, ...);
}
return null; // ← neither side is a workspace file → classic compare editor
````
• Unstaged changes (working tree vs. index/HEAD): the left side is the workspace file → unified diff works. ✅
• Staged changes (index vs. HEAD): both sides are Git revisions, neither is an IFileEditorInput → prepareUnifiedDiff returns null → classic compare. ❌
Not sure how we should handle that. Should we still compare against the workspace file? Or leave that to the old compare?
cc @tobiasmelcher
Contributor guide
Research direction
Start in CompareUIPlugin.prepareUnifiedDiff(...) and trace how IFileEditorInput, UnifiedDiffSource, and the fallback compare editor are selected. Compare the staged index-versus-HEAD path with the unstaged workspace-file path, then determine and document the expected unified-diff behavior for staged files. Done means the chosen behavior is implemented and covered by the relevant comparison checks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100