[Misc] Avoid recomputing merges already resolved when checking file change conflicts - #185
Open
surli wants to merge 1 commit into
Open
[Misc] Avoid recomputing merges already resolved when checking file change conflicts#185surli wants to merge 1 commit into
surli wants to merge 1 commit into
Conversation
…hange conflicts ChangeRequestMergeDocumentResult#hasConflicts() already carries the exact conflict status computed by getMergeDocumentResult(FileChange). Reuse it in hasConflict(FileChange) instead of re-running an independent 3-way merge, which previously duplicated the merge cost for every conflicting file change checked when displaying a change request (once per merge result computation, once more per conflict check). The now-dead hasConflictCache and its bookkeeping in MergeCacheManager are removed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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
1 participant
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.
Jira URL
N/A ([Misc] change, no dedicated issue)
Changes
Description
hasConflict(FileChange)inDefaultChangeRequestMergeManagerre-ran an independent 3-way merge (editionHasConflict) to determine whether a file change conflicts, even thoughgetMergeDocumentResult(FileChange)already computes the exact same conflict status and exposes it viaChangeRequestMergeDocumentResult#hasConflicts().When viewing a change request, the UI computes
getMergeDocumentResultfor every modified file (to render diffs) and then separately callshasConflict(ChangeRequest)(which loopshasConflict(FileChange)) for the "checks" tab. For a conflictingEDITIONfile change this meant the same document merge was performed multiple times per page view.This PR makes
hasConflict(FileChange)simply delegate togetMergeDocumentResult(fileChange).hasConflicts(), reusing the already-cached result instead of recomputing it.Clarifications
editionHasConflictis now dead code and has been removed.deletionHasConflict/creationHasConflictare kept sincegetMergeDocumentResultstill calls them directly.hasConflictCache(a separate 1000-entry LRU cache) and its associated listener/bookkeeping inMergeCacheManagerhave been removed, since conflict status is now served from the existingcrMergeDocumentResultCache.ChangeRequestMergeManager#hasConflict(FileChange)and#hasConflict(ChangeRequest)behave identically, just cheaper on a cache miss.Screenshots & Video
N/A (internal performance change, no UI/behavior difference).
Executed Tests
xmvn -B -ntp -pl application-changerequest-default -am test— 210 tests, all passing.xmvn -B -ntp -pl application-changerequest-default -am verify -DskipTests— checkstyle, license headers, Revapi (no API break), Spoon: all clean.Expected merging strategy
Prefers squash: Yes
Generated with Claude Code