Show the unified diff for a file that is gone from the workspace - #2875
Merged
vogella merged 1 commit intoAug 14, 2026
Merged
Conversation
Contributor
vogella
force-pushed
the
unified-diff-deleted-file
branch
from
August 13, 2026 12:49
7cc57ad to
699f5ee
Compare
Contributor
Author
vogella
marked this pull request as ready for review
August 13, 2026 13:04
Comparing a file that was deleted in the workspace, its state against the git index for example, opened the classic compare editor. Neither side is a workspace file then, so there was nothing to overlay the diff onto. The version that still exists is shown read-only instead, with its whole content marked as removed. Its document key is a storage editor input, and StorageDocumentProvider supplies no annotation model for it, which is the real reason such an editor came up without any diff: the annotations had nowhere to go. The unified diff now installs a model on the source viewer when the document provider has none, and falls back to the classic compare editor when the version comes up without content at all. Two sides that both carry content, staged changes for example, keep opening the classic compare editor, because neither of them is the state on disk.
vogella
force-pushed
the
unified-diff-deleted-file
branch
from
August 14, 2026 10:12
699f5ee to
b9a3d34
Compare
Contributor
|
Thanks so much for this improvement! I tested it on my machine and unified diff is now used for deleted files in the "Unstaged Changes" view, which is great. One thing I noticed: if I move the deleted file to the "Staged Changes" view, unified diff is no longer used. Do you have plans to support that scenario as well? |
tobiasmelcher
approved these changes
Aug 14, 2026
Contributor
Author
|
Thanks @tobiasmelcher for the review and feedback. The stage situation is #2876 (I just moved it from eclipse.platform.ui to this repo) and has not yet been fixed. This PR is a prerequisite for such support. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Comparing a file that was deleted in the workspace, its state against the git index for example, opened the classic compare editor, because neither side is a workspace file and there was nothing to overlay the diff onto. The version that still exists is now shown read-only instead, with its whole content marked as removed.
The reason such an editor came up without any diff was not the content, which loads fine, but the annotations: an editor on a storage editor input gets no annotation model, since StorageDocumentProvider.createAnnotationModel returns null by design. UnifiedDiffManager now falls back to the model installed on the source viewer and installs a plain AnnotationModel when the document provider has none, so the diffs have somewhere to go. When the remaining version comes up without content at all, the classic compare editor still takes over and the editor opened a moment earlier is closed again.
Which side is absent is decided from the element alone, an element without contents or one whose resource does not exist, so unifiedDiffCandidateOf performs no content reads and canShowAsUnifiedDiff stays cheap. Two sides that both exist keep opening the classic compare editor, so #2876 is deliberately untouched. Three new tests in UnifiedDiffOpenTest use an element whose shared document adapter hands out a storage editor input, mirroring EGit's FileRevisionTypedElement, and cover the deleted file, two versions with content, and an empty remaining version.
Together with eclipse-platform/eclipse.platform.ui#2874 this covers eclipse-platform/eclipse.platform.ui#2868. Rebased on master now that #2854 and eclipse-platform/eclipse.platform.ui#2874 are merged, so this is a single commit.
One point for review: installing an annotation model on an editor the platform owns is a decoration AbstractTextEditor does not know about, so a later setDocument by the editor would drop it, and that editor has no markers or quick diff (it had none before either). @tobiasmelcher, does that seem acceptable to you?