fix(web): make the update button work on branches without tracking - #443
Conversation
Reported from a pi whose checkout sat on a local branch:
git pull failed (returncode=1): There is no tracking information for
the current branch. Please specify which branch you want to rebase
against.
The Tools tab reported that as "Update failed; check logs for details",
which tells the user nothing they can act on, and the underlying git
message never reached the UI at all.
A branch with no upstream is easy to end up on — checking one out by
name, restoring a backup, or following a guide that names a branch — and
until now it left the update button permanently broken with no way out
except SSH.
resolve_pull_command() now decides how to pull:
- upstream set -> git pull --rebase, as before
- no upstream, origin/<branch> -> git pull --rebase origin <branch>,
then attach tracking so the next update is a plain pull
- no upstream, no remote branch -> an error naming the branch and
pointing at Switch branch
- detached HEAD -> says so, rather than failing obscurely
That resolution happens BEFORE the stash. Previously the handler stashed
local changes and then discovered it could not pull, putting the user's
work away for an update that was never going to run.
Failures now surface git's own message instead of "check logs".
Adds a branch picker to the Tools tab, backed by GET
/system/git-branches (local + remote-only) and a checkout_branch action.
Switching attaches tracking, so Pull Latest works afterwards. Branch
names are validated against a strict pattern before reaching a subprocess
argument list.
Local edits block a checkout, as they should. Rather than a truncated
one-line error, the response carries git's full list of blocking files
and a can_retry_with_stash flag; the UI then offers "Stash and switch" as
an explicit choice. Stashing is never done unasked — putting someone's
edits away without consent is worse than refusing the switch.
Verified on the pi that produced the report: on its untracked 'audit'
branch the update now returns the actionable message, git-info reports
upstream='' and can_pull=false, and an injected branch name is rejected.
27 tests build real git repositories and cover each path, including the
stash route that could not be exercised safely on the device.
|
Warning Review limit reached
Next review available in: 31 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Up to standards ✅🟢 Issues
|
1 participant
The report
From a pi's logs when using Update in the Tools tab:
The UI showed "Update failed; check logs for details" — the actual git message never reached the user, and there was no way to fix it without SSH.
A branch with no upstream is easy to land on: checking one out by name, restoring a backup, or following a guide that names a branch. Once there, the update button is permanently broken.
Fix
resolve_pull_command()decides how to pull:git pull --rebase(unchanged)origin/<branch>existsgit pull --rebase origin <branch>, then attach tracking so next time is a plain pullThe resolution runs before the stash. Previously the handler stashed local changes and then found it couldn't pull — putting the user's work away for an update that was never going to happen.
Failures now surface git's own message rather than "check logs".
Branch picker
New
GET /system/git-branches(local + remote-only) and acheckout_branchaction, wired to a dropdown in the Tools tab. Switching attaches tracking, so Pull Latest works afterwards. The git panel now shows the tracking state up front, so the problem is visible before clicking Update.Branch names are validated against a strict pattern before reaching a subprocess argument list.
Local edits
They block a checkout, as they should. Instead of a truncated one-liner, the response carries git's full list of blocking files plus
can_retry_with_stash, and the UI offers "Stash and switch" as an explicit choice.Stashing is never done unasked — putting someone's edits away without consent is worse than refusing the switch.
Verification
On the pi that produced the report (untracked
auditbranch):Branch 'audit' has no upstream and there is no origin/audit to pull from. Use Switch branch…git-info→upstream: '',can_pull: falseweb_interface/blueprints/api_v3.py,can_retry_with_stash: true{"branch": "evil;rm -rf /"}→Invalid branch name27 tests build real git repositories rather than mocking git, covering every path above — including the stash route, which couldn't be exercised safely on the device. Web suite: 229 passed, 1 skipped. New tests are picked up automatically by the full-tree CI invocation.