Split off from PR review feedback on #49.
Original feedback
collect_conflicted_files can fall back to a repo-relative path for conflicts outside the workspace subdirectory. That breaks the contract expected by git_stage_resolved (which resolves paths relative to workspace_root and rejects ..), so the commit panel's "Mark resolved" action will fail or target the wrong path when a merge conflict exists outside the opened subdirectory workspace.
— @copilot-pull-request-reviewer on this review comment
Background
sync_workspace/complete_merge (src-tauri/src/git_sync.rs) operate on the whole Git repository, not just the workspace subdirectory the app has open. If a pull conflicts on a file outside that subdirectory, the merge is genuinely stuck until it's resolved — but collect_conflicted_files (src-tauri/src/git_commit.rs) only knows how to report paths relative to the workspace, so it drops that entry from GitStatus.conflictedFiles rather than exposing an unusable path. The user sees "0 conflicts" while complete_merge keeps refusing with UnresolvedConflicts, with no clue why — a real, if narrow, dead end (subdirectory workspace opened on a repo where a network sync hits a conflict outside it).
Proposed fix
Surface the state honestly instead of listing a path the UI can't act on:
- Add a distinct signal to
GitStatus — e.g. conflictsOutsideWorkspace: usize (count) or a boolean — computed alongside conflictedFiles in collect_conflicted_files/status_for_workspace_blocking.
- In the commit panel merge UI, when that count is non-zero, show a message like "N merge conflict(s) exist outside this workspace — resolve them in a terminal" instead of (or alongside) the actionable per-file list, so "Complete merge" staying disabled makes sense to the user.
stage_resolved/resolve_workspace_path's workspace-scoping (rejecting ..) is a deliberate path-safety boundary and shouldn't be loosened for this.
Source
Split off from PR review feedback on #49.
Original feedback
— @copilot-pull-request-reviewer on this review comment
Background
sync_workspace/complete_merge(src-tauri/src/git_sync.rs) operate on the whole Git repository, not just the workspace subdirectory the app has open. If a pull conflicts on a file outside that subdirectory, the merge is genuinely stuck until it's resolved — butcollect_conflicted_files(src-tauri/src/git_commit.rs) only knows how to report paths relative to the workspace, so it drops that entry fromGitStatus.conflictedFilesrather than exposing an unusable path. The user sees "0 conflicts" whilecomplete_mergekeeps refusing withUnresolvedConflicts, with no clue why — a real, if narrow, dead end (subdirectory workspace opened on a repo where a network sync hits a conflict outside it).Proposed fix
Surface the state honestly instead of listing a path the UI can't act on:
GitStatus— e.g.conflictsOutsideWorkspace: usize(count) or a boolean — computed alongsideconflictedFilesincollect_conflicted_files/status_for_workspace_blocking.stage_resolved/resolve_workspace_path's workspace-scoping (rejecting..) is a deliberate path-safety boundary and shouldn't be loosened for this.Source
src-tauri/src/git_commit.rs:252(collect_conflicted_files)