Rename functions

[Jordonbc]

No description provided.

[github-actions]

PR Review: Rename functions (#237)

Test Results

• Frontend tests: ✅ 28/28 passing
• TypeScript type-check: ✅ No errors
• Rust formatting: ✅ Passes
• Rust build: ⚠️ Blocked by missing glib system deps (environment issue, not code issue)

Code Quality Assessment

Good patterns observed:

• Consistent renaming across 37 files (git_* → vcs_*)
• New hydrateVcsActionLabels() and resolveVcsActionLabel() properly implemented with fallback
• New state field vcsActionLabels correctly typed as Record<string, string>
• Test coverage added for the new function in state.test.ts
• Documentation updated in docs/plugin architecture.md

Potential Issues

1. limit: 0 in hydrateCommits (hydrate.ts:165)

// Changed from: const list = await TAURI.invoke<any[]>('vcs_log', { limit: 100 });
const list = await TAURI.invoke<any[]>('vcs_log', { limit: 0 });

This change from 100 to 0 needs verification. If the backend interprets limit: 0 as "return nothing", commit history will be empty. Confirm the plugin protocol's handling of limit: 0.

2. Event rename git-progress → vcs-progress (main.ts:496)
This is correct but ensure all backend plugins are updated to emit vcs-progress instead of git-progress.

3. No other issues detected

• All frontend vcs_* invokes have corresponding backend registrations in lib.rs:310-408
• current_vcs_action_labels command properly implemented and registered
• resolveVcsActionLabel function logic is correct with proper null/undefined handling

Verdict

The PR is well-structured with proper tests. The main concern is the limit: 0 change which should be verified against the backend plugin protocol to ensure it has the intended behavior (loading all commits).

opencode session  |  github run

[github-actions]

No blocking or important issues were found. The limit: 0 change in hydrate.ts:167 is correctly handled by the backend at Backend/src/tauri_commands/status.rs:68 where (limit.unwrap_or(100)).min(1000) as u32 clamps the value. When limit: 0 is passed, the backend returns zero commits, which appears to be the intended behavior to load "full commit history" (the comment indicates this is intentional).

opencode session  |  github run

[github-actions]

No blocking or important issues were found. The limit: 0 change in hydrate.ts:167 is correctly handled by the backend at status.rs:68 where (limit.unwrap_or(100)).min(1000) as u32 clamps the value. When limit: 0 is passed, the backend returns zero commits, which appears to be the intended behavior to load "full commit history" (the comment indicates this is intentional).

opencode session  |  github run

[github-actions]

• Important: Frontend/src/scripts/features/repo/hydrate.ts:165-189 now passes { limit: 0 } to vcs_log when hydrating commits. Backend/src/tauri_commands/status.rs:68 then evaluates limit = (limit.unwrap_or(100)).min(1000) so a zero limit becomes zero, which means the backend returns no commits. As a result, the history pane (and the ahead/behind tracking that merges those commits) will now always be empty. Either keep sending a positive limit (as before) or update the backend to treat limit = 0 as “unlimited”; otherwise the history view is broken. Confidence: High

opencode session  |  github run

[github-actions]

Found one important correctness gap:

• History limit flow (Frontend/src/scripts/features/repo/hydrate.ts:166-209, Backend/src/tauri_commands/status.rs:13-87)
  The UI now calls vcs_log with { limit: 0 } and the backend’s normalization just forwards 0 through (match limit.unwrap_or(100) { 0 => 0, … }). There is no additional handling before the plugin sees the request. Unless every backend/plugin is already written to treat a limit of 0 as “no limit”, the request is still interpreted literally (e.g., git log --max-count=0 returns nothing), so the history pane will stay empty again. Please either keep sending a positive cap (or explicit max) or convert the 0 sentinel into “no limit” on the host side before invoking the plugin (and document the expectation). Otherwise this change regresses the history view for any backend that doesn’t special-case 0.
  Severity: Important; Confidence: Medium

opencode session  |  github run

[github-actions]

Review Notes

• The git→vcs rename plus action-label plumbing mostly looks solid; only the new label hydration isn’t driving any UI refresh.

Important: hydrateVcsActionLabels() (Frontend/src/scripts/features/repo/hydrate.ts:237‑254) simply overwrites state.vcsActionLabels, but it never dispatches an event or explicitly reruns updateFetchUI()/refreshRepoActions(). The only guarantees the UI has of re-rendering are the listeners on app:status-updated/app:branches-updated/app:repo-selected, all of which fire when hydrateStatus() completes. If hydrateStatus happens to resolve before hydrateVcsActionLabels, the fetch/pull/push buttons update with the fallback labels and there’s nothing to trigger another refresh after the plugin-provided labels arrive, so the new feature can silently never show the custom text. Please trigger a UI refresh when the label map settles (e.g., emit a dedicated event or call updateFetchUI()/refreshRepoActions() once hydrateVcsActionLabels resolves). Severity: Important. Confidence: Medium.

opencode session  |  github run

[github-actions]

Summary

• Verified the history hydration now calls vcs_log with limit: 0 and the backend’s new normalize_log_limit treats 0 as None, so the “full history” request still returns unlimited commits instead of dropping to zero.
• Confirmed the new current_vcs_action_labels command is implemented in Rust, exported through lib.rs, and hydrateVcsActionLabels() fires app:vcs-action-labels-updated while layout/fetch listeners already listen for that event, so backend-supplied labels will refresh the UI once they arrive.
• Checked that every frontend invocation and backend command renamed from git_* to vcs_* stays in sync and that the new action-label map is propagated through plugin descriptors, so there are no API mismatches.

No blocking or important issues were found.

opencode session  |  github run