Skip to content

feat(cli): Auto-detect explicit remote URLs in positional arguments#1145

Merged
yamadashy merged 3 commits intomainfrom
feat/auto-detect-remote-url
Feb 17, 2026
Merged

feat(cli): Auto-detect explicit remote URLs in positional arguments#1145
yamadashy merged 3 commits intomainfrom
feat/auto-detect-remote-url

Conversation

@yamadashy
Copy link
Owner

@yamadashy yamadashy commented Feb 8, 2026

Allow users to run repomix https://github.com/user/repo or repomix git@github.com:user/repo.git without the --remote flag.

Only explicit URL formats (https:// and git@) are auto-detected. Shorthand format (owner/repo) is not auto-detected to avoid ambiguity with local directory paths.

Closes #1120

Checklist

  • Run npm run test
  • Run npm run lint

Open with Devin

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @yamadashy, 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 streamlines the user experience for the repomix command-line interface by enabling automatic recognition of full remote repository URLs (both HTTPS and SSH git@ formats) when passed directly as arguments. This enhancement allows users to omit the --remote flag for these explicit URL types, making CLI usage more intuitive. The change is carefully implemented to avoid ambiguity with local directory paths by not auto-detecting shorthand repository formats.

Highlights

  • CLI Auto-detection: The repomix CLI now automatically detects explicit remote URLs (starting with https:// or git@) when provided as positional arguments, removing the need for the --remote flag.
  • New Utility Function: Introduced isExplicitRemoteUrl in src/core/git/gitRemoteParse.ts to identify explicit remote URL formats, distinguishing them from shorthand or local paths.
  • Enhanced Test Coverage: Added new unit tests to tests/cli/cliRun.test.ts and tests/core/git/gitRemoteParse.test.ts to validate the auto-detection logic and the isExplicitRemoteUrl function, including cases for prioritization of the --remote flag.

🧠 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.

Changelog
  • src/cli/cliRun.ts
    • Imported isExplicitRemoteUrl from ../core/git/gitRemoteParse.js.
    • Added conditional logic within runCli to check if a single positional argument is an explicit remote URL and, if so, execute the runRemoteAction with it.
  • src/core/git/gitRemoteParse.ts
    • Implemented a new exported function isExplicitRemoteUrl(value: string) which returns true if the value starts with https:// or git@, and false otherwise.
    • Added JSDoc comments for the new function.
  • src/index.ts
    • Exported the newly added isExplicitRemoteUrl function to make it part of the public API.
  • tests/cli/cliRun.test.ts
    • Added new test cases to verify that runCli correctly auto-detects HTTPS URLs and calls runRemoteAction.
    • Added new test cases to verify that runCli correctly auto-detects git@ SSH URLs and calls runRemoteAction.
    • Added a test case to confirm that shorthand formats (user/repo) are not auto-detected as remote URLs and fall back to runDefaultAction.
    • Added a test case to ensure that an explicitly provided --remote flag takes precedence over any auto-detected URL.
  • tests/core/git/gitRemoteParse.test.ts
    • Imported isExplicitRemoteUrl for testing.
    • Added a new describe block for isExplicitRemoteUrl tests.
    • Included tests for various valid HTTPS and git@ SSH URLs, expecting true.
    • Included tests for shorthand formats, local paths, http:// URLs, and empty strings, expecting false.
Activity
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 8, 2026

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

This PR implements auto-detection of explicit remote URLs passed as positional CLI arguments, routing them to runRemoteAction instead of treating them as local paths. A new utility function isExplicitRemoteUrl() was added to detect HTTPS and SSH URL formats, exported publicly, and comprehensive test coverage was added to validate the feature and precedence rules.

Changes

Cohort / File(s) Summary
Core Git Remote Utilities
src/core/git/gitRemoteParse.ts
Added new exported function isExplicitRemoteUrl() that returns true for URLs starting with "https://" or "git@".
CLI Auto-detection Logic
src/cli/cliRun.ts
Imported isExplicitRemoteUrl() and added logic to detect explicit remote URLs in single positional arguments and route them to runRemoteAction before falling back to default action.
Public API Exports
src/index.ts
Updated exports to include isExplicitRemoteUrl alongside existing remote parsing functions.
CLI Test Coverage
tests/cli/cliRun.test.ts
Added tests for URL auto-detection (HTTPS and SSH formats), non-triggering shorthand format, and explicit --remote flag precedence.
Git Parsing Test Coverage
tests/core/git/gitRemoteParse.test.ts
Added test suite for isExplicitRemoteUrl() covering acceptance of HTTPS/SSH URLs and rejection of shorthand, local paths, HTTP URLs, and empty strings.

Sequence Diagram

sequenceDiagram
    participant User
    participant CLI as cliRun.ts
    participant Parser as gitRemoteParse.ts
    participant RemoteAction as runRemoteAction()
    participant DefaultAction as runDefaultAction()

    User->>CLI: Pass URL as positional argument
    CLI->>CLI: Check if exactly one arg
    CLI->>Parser: isExplicitRemoteUrl(arg)
    Parser-->>CLI: true (for https:// or git@)
    CLI->>RemoteAction: Route to remote handler
    RemoteAction-->>User: Clone & process remote repo

    User->>CLI: Pass shorthand (user/repo)
    CLI->>Parser: isExplicitRemoteUrl(arg)
    Parser-->>CLI: false
    CLI->>DefaultAction: Fall back to default
    DefaultAction-->>User: Process as local path
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Possibly related PRs

🚥 Pre-merge checks | ✅ 4 | ❌ 1
❌ Failed checks (1 inconclusive)
Check name Status Explanation Resolution
Linked Issues check ❓ Inconclusive The PR implementation partially addresses issue #1120: it adds explicit URL auto-detection but does not implement the full proposed precedence logic checking local path existence before treating as remote. Verify that the implementation correctly handles the precedence: explicit --remote flag first, then local path check before treating as remote URL, as outlined in issue #1120.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title 'Auto-detect explicit remote URLs in positional arguments' directly and accurately summarizes the main change in the PR.
Description check ✅ Passed The description explains the feature, provides examples, clarifies the scope (explicit URLs only, not shorthand), references the linked issue, and includes all checklist items marked as completed.
Out of Scope Changes check ✅ Passed All changes are scoped to adding the isExplicitRemoteUrl function and integrating it into the CLI flow, which directly supports the auto-detection feature without introducing unrelated modifications.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat/auto-detect-remote-url

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@codecov
Copy link

codecov bot commented Feb 8, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.19%. Comparing base (63a2b80) to head (1d5297c).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1145      +/-   ##
==========================================
+ Coverage   87.18%   87.19%   +0.01%     
==========================================
  Files         116      116              
  Lines        4385     4390       +5     
  Branches     1021     1022       +1     
==========================================
+ Hits         3823     3828       +5     
  Misses        562      562              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@claude
Copy link
Contributor

claude bot commented Feb 8, 2026

Code Review: Auto-detect explicit remote URLs in positional arguments

Overall Assessment: ✅ Approve

This is a clean, well-implemented feature that improves CLI ergonomics by allowing users to run repomix https://github.com/user/repo directly without the --remote flag.

Strengths

  1. Clear design decision: Intentionally excludes shorthand format (owner/repo) to avoid ambiguity with local directory paths - this is the right call.
  2. Proper precedence: The --remote flag correctly takes priority over auto-detection (checked first at line 275-277).
  3. Comprehensive tests: Good coverage including HTTPS URLs, SSH URLs, shorthand exclusion, and --remote flag priority.
  4. Minimal footprint: Only 8 lines of core implementation with good separation of concerns.

Potential Considerations

Details

Edge Cases to Consider

  1. Multiple directories with URL: The check directories.length === 1 correctly handles this, but there's no explicit test for cases like repomix https://github.com/user/repo ./local-dir - this falls through to default action which may or may not be intentional.

  2. http:// URLs: The implementation correctly rejects http:// URLs (only https:// is supported). This is intentional per the tests, but users might be surprised if they use http://. Consider whether a warning message would be helpful.

  3. SSH URL variants: The git@ prefix check handles the most common SSH format, but there are other SSH URL formats like ssh://git@github.com/user/repo.git. These would not be auto-detected but would work with --remote.

Documentation

The PR description mentions updating the help text via --remote option description. The current description says "Clone and pack a remote repository (GitHub URL or user/repo format)" - it might be worth noting in the CLI help that explicit URLs are now auto-detected.

Premortem Analysis

Potential Failure Scenarios
Scenario Risk Level Mitigation
User has a local folder starting with https:// or git@ Very Low Highly unlikely folder naming; edge case not worth handling
Users expect owner/repo to auto-detect as remote Low Documented in PR description; predictable behavior
Future URL schemes (e.g., gitlab://) Low Can be extended later; current implementation is conservative

Minor Suggestions (Not Blocking)

  1. Consider adding a test case for repomix https://github.com/user/repo ./local-dir to document expected behavior for multiple arguments.

  2. The trace log at line 281 is helpful for debugging - good addition.

LGTM! This is a straightforward UX improvement with solid implementation.

Copy link
Contributor

@devin-ai-integration devin-ai-integration bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 4 additional findings.

Open in Devin Review

gemini-code-assist[bot]

This comment was marked as resolved.

Allow users to run `repomix https://github.com/user/repo` or
`repomix git@github.com:user/repo.git` without the `--remote` flag.

Only explicit URL formats (https:// and git@) are auto-detected.
Shorthand format (owner/repo) is not auto-detected to avoid
ambiguity with local directory paths.

Closes #1120
@yamadashy yamadashy force-pushed the feat/auto-detect-remote-url branch from 07b518a to 540e8dd Compare February 17, 2026 13:40
@cloudflare-workers-and-pages
Copy link

cloudflare-workers-and-pages bot commented Feb 17, 2026

Deploying repomix with  Cloudflare Pages  Cloudflare Pages

Latest commit: 1d5297c
Status: ✅  Deploy successful!
Preview URL: https://fbb87ed6.repomix.pages.dev
Branch Preview URL: https://feat-auto-detect-remote-url.repomix.pages.dev

View logs

@claude
Copy link
Contributor

claude bot commented Feb 17, 2026

Code Review (Follow-up after rebase)

Overall Assessment: ✅ Approve

The code is unchanged from the previous review. The rebase to current main introduces no conflicts or new concerns. My previous review still applies fully.

One Additional Observation

Looking more closely at the interaction between isExplicitRemoteUrl and parseRemoteValue, there's a subtle but safe asymmetry worth noting:

  • isExplicitRemoteUrl accepts https:// and git@ prefixes
  • parseRemoteValue handles shorthand, Azure DevOps URLs, and then delegates to git-url-parse

If a user passes something like https://not-a-real-url as a positional argument, isExplicitRemoteUrl would return true, routing it to runRemoteAction, which would then fail during the clone step with a clear git error. This is acceptable behavior — it's the same thing that happens when using --remote https://not-a-real-url today, so there's no regression.

Gemini's Suggestion on ssh:// and git:// Protocols

Details

Gemini suggested adding support for ssh:// and git:// protocols. This is a reasonable enhancement but out of scope for this PR. The current implementation covers the two most common explicit URL formats. Adding more protocols could be a follow-up if there's user demand. The conservative approach here is correct — it's easier to add more protocols later than to remove incorrectly matched ones.

Summary

Clean PR, ready to merge. No changes needed.

yamadashy and others added 2 commits February 17, 2026 22:54
…detection

The existing --remote flag already supports ssh:// and git:// protocols
via git-url-parse, so auto-detection should cover them as well.
@yamadashy yamadashy merged commit cb97645 into main Feb 17, 2026
54 of 55 checks passed
@yamadashy yamadashy deleted the feat/auto-detect-remote-url branch February 17, 2026 14:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Auto-detect URLs and treat as --remote for CLI

1 participant