Skip to content

Conversation

@majiayu000
Copy link
Contributor

Summary

When specifying a repository for gh repo set-default, users can now use a git remote name (e.g., "origin", "upstream") instead of the full OWNER/REPO format.

Changes

  • Modified argument parsing to first check if the argument is a git remote name
  • If found as a remote name, uses the corresponding repository
  • Falls back to OWNER/REPO format if not found as a remote
  • Added documentation example for using remote names
  • Added test case for remote name argument

Example

# Before: had to use full repo format
gh repo set-default myorg/some-repo-name

# Now: can also use remote name
gh repo set-default origin

Test plan

  • Added test case for "remote name argument"
  • All existing tests pass
  • Updated help example to show remote name usage

Fixes #9149

When specifying a repository for `gh repo set-default`, users can now
use a git remote name (e.g., "origin", "upstream") instead of the
full OWNER/REPO format.

The command first checks if the argument is a git remote name. If
found, it uses the corresponding repository. Otherwise, it falls
back to parsing the argument as OWNER/REPO format.

Example:
  gh repo set-default origin

Fixes cli#9149

Signed-off-by: majiayu000 <1835304752@qq.com>
@majiayu000 majiayu000 requested a review from a team as a code owner December 26, 2025 11:21
@majiayu000 majiayu000 requested a review from babakks December 26, 2025 11:21
@cliAutomation cliAutomation added the external pull request originating outside of the CLI core team label Dec 26, 2025
Copy link
Member

@babakks babakks left a comment

Choose a reason for hiding this comment

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

Thanks for the PR, @majiayu000! 🙏 It's almost there, except for a small modification.

I haven't yet fully reviewed the tests, though.

Copy link
Member

@babakks babakks left a comment

Choose a reason for hiding this comment

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

Thanks for the fix, @majiayu000! 🍻

We just need to get rid of the redundant if-statement (see the first/only comment), and then I think we're good to ship this.


Just as a bit of context, most gh commands work in a two-stage kind of way: 1) pre-run (e.g. arg/flag validation, which are done within cmd.RunE), and 2) run (done in a top-level runX function). In most cases, we restrict the pre-run stage to only static/offline checks that do not need any API calls, or git invocations.

The repo set-default command has already been a bit of an exception due to the call to opts.GitClient.IsLocalGitRepo which invokes git rev-parse under the hood. Now with the new remote lookup step (in cmd.RunE) we're bending the rules a bit more.

That said, I'm not going to ask you for the improvement in this PR, of course unless you're up for it, in which case please let me know.

Anyway, I'm going to capture what should be done here:

  1. In pre-run, try parsing the arg as a repo name.
    • If it's not, just leave opts.Repo unassigned (i.e. nil).
  2. In run:
    1. Check current directory is a git (sub)dir.
      • If it's not, bail out.
    2. if opts.Repo is nil, try parsing the arg as a remote.
      • if it's not, bail out with an error like "given arg is not a valid repo or git remote".

This change will require updating the tests, but has the merit of making the pre-run stage purely static/offline.

@majiayu000
Copy link
Contributor Author

Fixed the redundant Remotes nil check (factory always sets it) and adjusted tests to always provide a Remotes func. Pushed to fix-9149-set-default-remote-name.

Copy link
Contributor Author

@majiayu000 majiayu000 left a comment

Choose a reason for hiding this comment

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

Addressed: removed redundant Remotes nil check; tests now always supply Remotes func. Ready for re-review.

Copy link
Member

@babakks babakks left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks, @majiayu000! 🍻

@babakks babakks merged commit 559e729 into cli:trunk Jan 14, 2026
11 checks passed
@majiayu000 majiayu000 deleted the fix-9149-set-default-remote-name branch January 15, 2026 02:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

external pull request originating outside of the CLI core team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

improve gh repo set-default to work with remote names

3 participants