fix: detect no remote branch #649
Conversation
- Introduced a new route for adding remotes to git worktrees. - Enhanced the PushToRemoteDialog component to support adding new remotes, including form handling and error management. - Updated the API client to include an endpoint for adding remotes. - Modified the worktree state management to track the presence of remotes. - Improved the list branches handler to check for configured remotes. This update allows users to easily add remotes through the UI, enhancing the overall git workflow experience.
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. 📝 WalkthroughWalkthroughThis PR introduces a complete add-remote feature for Git repositories within worktrees. It adds a backend POST endpoint to add Git remotes with validation and optional fetching, extends the list-branches response with a hasAnyRemotes flag, updates the frontend API client and type definitions, and refactors the push-to-remote dialog to support adding remotes with a new form-based UI flow. Changes
Sequence DiagramsequenceDiagram
participant UI as UI (Dialog)
participant Client as HTTP Client
participant Server as Server Handler
participant Git as Git Process
UI->>Client: handleAddRemote(worktreePath, remoteName, remoteUrl)
Client->>Server: POST /api/worktree/add-remote
Server->>Server: Validate request payload
Server->>Git: git remote (check existing)
Git-->>Server: List of existing remotes
Server->>Server: Check if remoteName already exists
alt Remote already exists
Server-->>Client: 400 error (REMOTE_EXISTS)
Client-->>UI: Display error "Remote already exists"
else Remote does not exist
Server->>Git: git remote add <remoteName> <remoteUrl>
Git-->>Server: Success
Server->>Git: git fetch <remoteName> (timeout: 30s)
alt Fetch succeeds
Git-->>Server: Fetch successful
Server-->>Client: 200 success (fetched: true)
else Fetch fails
Git-->>Server: Fetch error
Server-->>Client: 200 success (fetched: false, message: error)
end
Client->>UI: Update remotes list, select new remote, clear form
UI-->>UI: Re-render with new remote available
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 3❌ Failed checks (3 warnings)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
Summary of ChangesHello @Shironex, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces the ability for users to add Git remotes directly within the application, enhancing the workflow for managing repositories without pre-configured remotes. It also refines the display of local-only branches and improves the overall user experience in the 'Push to Remote' dialog by integrating remote addition seamlessly. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new API endpoint and corresponding UI functionality to allow users to add new Git remotes to a worktree. The server-side changes include a new /add-remote POST route with input validation for remote name and URL, checks for existing remotes, and execution of git remote add and an optional git fetch. Unit tests for this new endpoint cover various validation and success/failure scenarios. On the UI side, the 'Push to Remote' dialog is enhanced to include an 'Add Remote' form, allowing users to input a new remote's name and URL. This form appears automatically if no remotes are found, and includes client-side validation, API integration, and dynamic UI updates. Additionally, the list-branches endpoint now reports if a repository has any remotes, and the UI's worktree actions dropdown has been updated to visually indicate local-only branches with a 'local only' tag and a CloudOff icon. Review comments suggested consolidating repetitive validation checks in the server-side handler, logging errors in an empty catch block for debugging, and moving a utility function to a shared location for reusability, as well as fixing a UI bug where an error message was hidden by the 'Add Remote' form.
apps/ui/src/components/views/board-view/dialogs/push-to-remote-dialog.tsx
Outdated
Show resolved
Hide resolved
apps/ui/src/components/views/board-view/dialogs/push-to-remote-dialog.tsx
Outdated
Show resolved
Hide resolved
Shironex
added
Bug
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@apps/server/src/routes/worktree/routes/add-remote.ts`:
- Around line 1-6: Update the header comment in the POST /add-remote file to
reference the actual middleware used: change the mention of requireValidWorktree
to requireGitRepoOnly so the comment matches the route registration; locate the
top-of-file comment in add-remote.ts and replace the middleware name accordingly
(keep the rest of the note intact).
In `@apps/ui/src/components/views/board-view/dialogs/push-to-remote-dialog.tsx`:
- Around line 98-103: The effect that auto-opens the add-remote form currently
runs whenever isLoading is false and remotes.length === 0, which hides the error
view when listRemotes fails; update the useEffect (the effect that calls
setShowAddRemoteForm) to also require that there is no error (e.g., add a check
for !error) and include error in the dependency array so the auto-open only
triggers on an empty remotes list when no error is present, leaving the error
view visible for retries.
🧹 Nitpick comments (3)
apps/ui/src/types/electron.d.ts (1)
992-1007: Consider reusing shared AddRemote response types.
This avoids type drift between UI and@automaker/typesand keeps the API surface centralized.♻️ Suggested type reuse
-import type { ClaudeUsageResponse, CodexUsageResponse } from '@/store/app-store'; +import type { ClaudeUsageResponse, CodexUsageResponse } from '@/store/app-store'; +import type { AddRemoteResponse, AddRemoteErrorResponse } from '@automaker/types'; @@ addRemote: ( worktreePath: string, remoteName: string, remoteUrl: string - ) => Promise<{ - success: boolean; - result?: { - remoteName: string; - remoteUrl: string; - fetched: boolean; - message: string; - }; - error?: string; - code?: 'REMOTE_EXISTS'; - }>; + ) => Promise<AddRemoteResponse | AddRemoteErrorResponse>;apps/ui/src/hooks/queries/use-worktrees.ts (1)
213-219: Consider normalizingisRemotein branch resultsSince
isRemoteis now non-optional, a defensive boolean cast here prevents accidentalundefinedif an older backend omits it.Suggested change
- branches: result.result?.branches ?? [], + branches: (result.result?.branches ?? []).map((branch) => ({ + ...branch, + isRemote: !!branch.isRemote, + })),apps/server/src/routes/worktree/index.ts (1)
182-188: Verify middleware scope for/add-remote
/list-remotesusesrequireValidWorktree, but/add-remoteonly usesrequireGitRepoOnly. If this should be restricted to registered worktrees, align the middleware for consistency.Possible alignment
router.post( '/add-remote', validatePathParams('worktreePath'), - requireGitRepoOnly, + requireValidWorktree, createAddRemoteHandler() );
Summary by CodeRabbit
Release Notes
New Features
Tests
✏️ Tip: You can customize this high-level summary in your review settings.