Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@ADKaster
Copy link

@ADKaster ADKaster commented Dec 4, 2024

Fixes #9149

I'm not sure if this is a complete fix, as the UX for passing a random string (or a string you thought was a remote name) is now a bit worse.

It also doesn't actually check with git whether the remote name actually corresponds with a real git remote, which might give a better experience as well.

But this does seem to be the minimum change to let me type gh repo set-default upstream instead of having to do gh repo set-default $(git remote get-url upstream), which was super annoying :).

Also perhaps there should be some magic sauce to add a remote named upstream or github if you specify it and the only remote is origin and you've cloned a fork?

@ADKaster ADKaster requested a review from a team as a code owner December 4, 2024 04:50
@ADKaster ADKaster requested a review from andyfeller December 4, 2024 04:50
@cliAutomation cliAutomation added the external pull request originating outside of the CLI core team label Dec 4, 2024
@andyfeller
Copy link
Member

@ADKaster : Thanks for opening this PR and apologies for delay following up! πŸ™‡ Catching up on the issue, I'm going to dig into this and the related code given the concerns you alluded to. πŸ‘

Copy link
Member

@andyfeller andyfeller left a comment

Choose a reason for hiding this comment

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

Thank you again for your patience! πŸ™‡ Couple of concerns regarding these changes that I think we can address and get this into ship shape!

Comment on lines +91 to +98
if len(args) > 0 {
var err error
opts.Repo, err = parseRepo(args[0], opts)
if err != nil {
return err
}
}

Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason this logic needed to be moved to later within RunE? Does this create a problem above because opts.Repo is unset?

Depending on the motivation for moving the logic, this might have to be undone as non-interactive usage will break because opts.Repo is unset.

RunE: func(cmd *cobra.Command, args []string) error {
if !opts.ViewMode && !opts.IO.CanPrompt() && opts.Repo == nil {
return cmdutil.FlagErrorf("repository required when not running interactively")
}

Comment on lines -81 to -88
if len(args) > 0 {
var err error
opts.Repo, err = ghrepo.FromFullName(args[0])
if err != nil {
return err
}
}

Copy link
Member

Choose a reason for hiding this comment

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

Does it make sense to move processing opts.Repo out of RunE and into setDefaultRun?

The spf13/cobra command hooks should be focused on translating cobra arguments and flags into variables that the application logic cares about, however this is no longer as simple as turning owner/repo into ghrepo.Interface. With the changes as-is, we're duplicating logic around remotes and starting to do more application-level behavior outside of the application code.

It might be cleaner and easier to test by changing opts.Repo to a string like opts.RepoOrRemote and defer checking remotes or parsing this as a repo until later in the logic:

if opts.Repo != nil {
for _, knownRepo := range knownRepos {
if ghrepo.IsSame(opts.Repo, knownRepo) {
selectedRepo = opts.Repo
break
}
}
if selectedRepo == nil {
return fmt.Errorf("%s does not correspond to any git remotes", ghrepo.FullName(opts.Repo))
}
}

  1. Error handling around remotes happened earlier in the logic
  2. Application has remote and resolved remote information
  3. RunE logic keeps this logic within the testable code

@154577674

This comment was marked as spam.

@154577674

This comment was marked as spam.

@andyfeller
Copy link
Member

@ADKaster : I want to give a gentle nudge if this is a PR you are still interested in contributing to the GitHub CLI. I understand you may have other priorities going on, however I'm unsure if you saw my comments above and if this is something you're still interested in.

@ADKaster
Copy link
Author

@andyfeller sorry for the lack of response! I did see the comments, but I didn't have the capacity to re-open my Go IDE and dive back into the code. I mostly opened this PR because I was annoyed that I had to do gh repo set-default $(git remote get-url upstream) to get the 'obvious' behavior πŸ˜… . I think that the reason I had to move that parameter around was because in order to query the set of repos, it had to be initialized first. I don't think I'll have the capacity to dive into this more deeply any time soon.

@andyfeller
Copy link
Member

@andyfeller sorry for the lack of response! I did see the comments, but I didn't have the capacity to re-open my Go IDE and dive back into the code. I mostly opened this PR because I was annoyed that I had to do gh repo set-default $(git remote get-url upstream) to get the 'obvious' behavior πŸ˜… . I think that the reason I had to move that parameter around was because in order to query the set of repos, it had to be initialized first. I don't think I'll have the capacity to dive into this more deeply any time soon.

I appreciate pain-driven development is what motivates a lot of OSS development! πŸ˜†

Thanks for the context. πŸ™‡ Given that, I'm going to see if I can shape this up and get it over the line. I wanted to check in before presuming. ❀️

Comment on lines +261 to +264
remotes, err := opts.Remotes()
if err != nil {
return nil, err
}
Copy link
Member

Choose a reason for hiding this comment

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

My major concern with the code as-is is that multiple calls to resolve git remotes via opts.Remotes() does not reuse previously cached results as stated in #10103.

Perhaps the expense isn't significant enough to move forward here. It is mostly a question whether instead of providing a function to resolve the remotes if an actual remote resolver is provided πŸ€”

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

4 participants