feat(source-control): integrate execution result and conflict status - #130
Closed
ClaudiaFang wants to merge 3 commits into
Closed
ClaudiaFang wants to merge 3 commits into
ClaudiaFang wants to merge 3 commits into
Conversation
PR130 — surface the three-state (success/conflict/failed) operation outcome
in the Source Control logic layer so the UI can render a batch summary
("7 completed / 3 conflicts / 1 failed"). No UI changes, no sync-domain
changes; reuses existing executor conflict semantics.
- OperationState: add 'conflict' to OperationStatus with conflict() — a
distinct lifecycle from 'failed' (needs-resolution, resolvable, not error).
- ExecutionResult (new): thin UI projection {completed, conflicts, failed}
as ChangeId[], derived in SourceControlActionService from existing
PushResults/SyncResult/RemoteDeleteResult (not a new sync model).
- SourceControlActionService: push/pull/deleteRemote/deleteLocal/
resolveConflict return Promise<ExecutionResult>; push reads
PushResults.conflictedPaths -> 'conflict' (conflict precedence over error);
new classify() helper maps per-path outcome to OperationStatus + result.
- SourceControlViewModel: expose lastOperationResult via
setOperationResult/clearOperationResult in SourceControlViewState.
Known asymmetry by design: PushResults exposes per-path conflictedPaths;
SyncResult (pull) carries only a conflict count, so pull conflicts surface
through change-model reclassification (kind:'conflict') on next refresh, not
this projection. The 'conflicts' filter stays change-model-driven; operation
'conflict' status is the per-change push outcome — complementary.
Verification: npx eslint . — 0 errors; npm run build — PASS incl. Obsidian
1.11.0 compatibility; npx vitest run — 66 files / 700 tests (source-control
logic 7 files / 60 tests).
ClaudiaFang
force-pushed
the
feat/source-control-integration
branch
from
August 22, 2026 09:07
2677fad to
b3379b7
Compare
PR131 / Phase 2 — reorganize Source Control UI state from scattered View-local fields + direct store access into one SourceControlState container, with the ViewModel as the single facade the View reads from and mutates through. Pure refactor; no behavior change (all 553 tests pass). State model (new src/logic/source-control/state/): - SourceControlState: thin container composing the change model + every UI state slice (selection, operation, filter, expanded nodes, selected change). Not a god-object — each slice keeps its own invariants/methods. - SelectionState: moved/renamed from PushSelectionStore (same API). - OperationState: moved from src/logic/source-control/ (incl. 'conflict' status from PR #130). - FilterState / ExpandedNodesState / SelectedChangeState: new slices that previously lived as View-local fields (active filter, collapsed sections/folders, selected change id). Facade: - SourceControlViewModel is constructed from SourceControlState and is the sole mutation surface (setFilter, toggleSection/Folder, selectForPush/ deselectFromPush, selectForDiff/clearSelection, getCollapsedFolders, setOperationResult/clear). The View reaches no store directly. - SourceControlView holds no state of its own and mutates only through the ViewModel; getFilter/getSelectedChangeId moved to the ViewModel. Constructor is now (viewModel, callbacks). - main.ts / SourceControlItemView construct SourceControlState; plugin exposes sourceControlState (replaces pushSelectionStore/operationState). - SourceControlFilter.matchesFilter selection param type is SelectionState. Tests: moved OperationState/PushSelectionStore tests into state/ (renamed to SelectionState.test.ts); new FilterState/ExpandedNodesState/SelectedChangeState tests; updated ViewModel/View/ItemView/ActionService tests for the new construction. Verification: npx eslint . — 0 errors; npm run build — PASS incl. Obsidian 1.11.0 compatibility; npx vitest run — 59 files / 553 tests.
…te-model refactor(source-control): unify UI state into SourceControlState
|
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.
PR130 — Source Control execution-result + conflict status
Stacks on #129 (
claude/source-control-foundation). Adds the three-state (success / conflict / failed) operation-outcome model to the Source Control logic layer so the UI can later render a batch summary ("7 completed / 3 conflicts / 1 failed").No UI changes. No sync-domain changes — reuses existing executor conflict semantics.
Changes
OperationStatusgains'conflict'+conflict()— a distinct lifecycle from'failed'(needs-resolution, resolvable, not an error).{ completed, conflicts, failed }: ChangeId[]+emptyExecutionResult(), derived inSourceControlActionServicefrom existingPushResults/SyncResult/RemoteDeleteResult— not a new sync model.push/pull/deleteRemote/deleteLocal/resolveConflictnow returnPromise<ExecutionResult>;pushreadsPushResults.conflictedPaths→'conflict'(conflict precedence over error); newclassify()helper maps per-path outcome toOperationStatus+ result in one pass.SourceControlViewState.lastOperationResult+setOperationResult/clearOperationResultfor batch-summary exposure.ExecutionResult.test.ts; extended OperationState (conflict lifecycle), ActionService (conflict mapping, mixed 7/3/1 batch, conflict-precedence, throw → all-failed, return-value contracts), ViewModel (result exposure).Design notes
PushResultsexposes per-pathconflictedPaths;SyncResult(pull) carries only aconflictscount. So push maps conflicts toChangeIds; pull conflicts surface through change-model reclassification (kind: 'conflict') on the next repository refresh, not via this projection.'conflicts'filter stays change-model-driven (change.kind === 'conflict'); operation'conflict'status is the per-change push outcome — complementary, not coupled.Verification
Manual Obsidian verification deferred (no runtime UI surface changed in this PR).
Roadmap:
docs/source-control-refactor/roadmap.md. Next: PR131 (Phase B — batch conflict workflow +ConflictClassifier).