Split out of #391, which removed the dead-control defect by disabling these two buttons. They are now honest about being unimplemented, but the functionality is still missing.
What exists already
The plumbing is mostly in place, which is why this is worth doing rather than dropping the buttons:
GitCli.RunIn(repoPath, args...) runs any git command scoped with git -C, safe under the concurrent fetches the app already performs.GitCli.HasUncommittedChanges(repoPath) answers "is there anything to commit".ImGuiPopups.InputString is already used for text entry (PopupSetDevDirectory, PopupAddNewGitHubOwner).QueueGitLog(label, result) surfaces a GitResult in the log panel.FetchRepo / PullRepo establish the background-Task pattern these should follow.
What needs deciding first
These are policy questions, not implementation details, and they are why #391 stopped short:
Commit
- What gets staged?
git add -A stages everything including untracked files, which is a surprising thing to do on someone else's working tree from a background click. Staging only tracked changes (git commit -a) is narrower. Neither should be chosen silently.
- Should the user see what will be committed before confirming? The app already computes diffs, so showing the file list is feasible.
- Author identity: the app currently sets none, so it relies on the user's global git config. That is probably right, but should be deliberate.
Push
- Which remote and branch?
git push with no arguments depends on the branch's upstream, which may not exist for a fresh branch.
- What happens on rejection?
PullRepo's comment records that unattended git operations swallowing failures already caused a bad bug here once — a rejected push must be surfaced, not logged and forgotten.
- Force-push must not be reachable from this UI.
Suggested approach
Follow the existing PullRepo shape: a confirming wrapper that gathers input and asks, then a plain method that runs git on a background Task and pipes the GitResult through QueueGitLog. Re-enable each button in the same change that implements it, and delete the corresponding half of the "Not implemented yet." tooltip.
GitCliTests drives real git against throwaway repositories under the temp path, so both actions can be covered there the way UncommittedChangesAreDetected covers the dirty-tree check.
Split out of #391, which removed the dead-control defect by disabling these two buttons. They are now honest about being unimplemented, but the functionality is still missing.
What exists already
The plumbing is mostly in place, which is why this is worth doing rather than dropping the buttons:
GitCli.RunIn(repoPath, args...)runs any git command scoped withgit -C, safe under the concurrent fetches the app already performs.GitCli.HasUncommittedChanges(repoPath)answers "is there anything to commit".ImGuiPopups.InputStringis already used for text entry (PopupSetDevDirectory,PopupAddNewGitHubOwner).QueueGitLog(label, result)surfaces aGitResultin the log panel.FetchRepo/PullRepoestablish the background-Taskpattern these should follow.What needs deciding first
These are policy questions, not implementation details, and they are why #391 stopped short:
Commit
git add -Astages everything including untracked files, which is a surprising thing to do on someone else's working tree from a background click. Staging only tracked changes (git commit -a) is narrower. Neither should be chosen silently.Push
git pushwith no arguments depends on the branch's upstream, which may not exist for a fresh branch.PullRepo's comment records that unattended git operations swallowing failures already caused a bad bug here once — a rejected push must be surfaced, not logged and forgotten.Suggested approach
Follow the existing
PullReposhape: a confirming wrapper that gathers input and asks, then a plain method that runs git on a backgroundTaskand pipes theGitResultthroughQueueGitLog. Re-enable each button in the same change that implements it, and delete the corresponding half of the "Not implemented yet." tooltip.GitCliTestsdrives real git against throwaway repositories under the temp path, so both actions can be covered there the wayUncommittedChangesAreDetectedcovers the dirty-tree check.