-
Notifications
You must be signed in to change notification settings - Fork 7.8k
Enable gh pr create from outside of a local git repo
#6527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…itory When failing to read information from the local git repository, silence that failure if `--repo` was given.
samcoe
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code is good and your approach works. I suggested an alternative approach in the comments, but it is non-blocking. Thanks for adding a test for this scenario.
| // TODO: consider obtaining remotes from GitClient instead | ||
| remotes, err := opts.Remotes() | ||
| if err != nil { | ||
| return nil, err | ||
| // When a repo override value is given, ignore errors when fetching git remotes | ||
| // to support using this command outside of git repos. | ||
| if opts.RepoOverride == "" { | ||
| return nil, err | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems a bit off to run opts.Remotes() when opts.RepoOverride is not a blank string since we know the results are irrelevant. What do you think about doing something like this:
var remotes ghContext.Remotes
if opts.RepoOverride == "" {
remotes, err = opts.Remotes()
if err != nil {
return nil, err
}
}There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good suggestion, but gh pr create is an odd command in it that the local git repo still has a purpose even if you've used the -R/--repo override.
In other commands, the presence of the --repo flag means that the local git repo should not even be considered; but in gh pr create the --repo flag can be used to change the base repo that the PR will be opened against; however the head branch, branch push status, head repo etc. can still be determined from the local git repo (if one exists). The pr create command being an exception like this may be counter-intuitive but is kept for backwards compatibility.
|
I might be missing something but there seems to have been a regression to this fix, when I'm running the command from outside of any git folder I get: $ gh pr create --repo me/my-repo --fill --assignee @me --base main --head some-update
could not compute title or body defaults: failed to run git: fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).I'm using the latest version: $ gh --version
gh version 2.53.0 (1980-01-01)
https://github.com/cli/cli/releases/tag/v2.53.0 |
|
My bad, the error spilled it out for my anyway, I can't use |
Fixes #5906
Fixes #5075