Conversation
| return err | ||
| } | ||
| renameTarget := "upstream" | ||
| renameCmd, err := git.GitCommand("remote", "rename", remoteName, renameTarget) |
There was a problem hiding this comment.
What happens here if remoteName is blank? If remoteName is blank should we use "origin"? I think that would mimic the behavior before #1882.
There was a problem hiding this comment.
I'm guessing the only way for remoteName to be blank is if the user passed --remote-name="", and in that case I expect that the command should fail since that isn't a valid value.
There was a problem hiding this comment.
this was my expectation as well, but we could notice and do a nicer error
There was a problem hiding this comment.
This looks good, but I had one additional expectation when it comes to --remote-name, and I'm wondering what your thoughts on it would be: what if passing a --remote-name unconditionally opted out of remote renaming behavior? i.e.
gh repo fork: renames "origin" remote if it already existsgh repo fork --remote-name=foo- doesn't ever rename any existing git remotes, even if "foo" existed- corollary:
gh repo fork --remote-name=origin- doesn't ever rename the "origin" remote
- corollary:
It's a subtle difference from the current state of this PR, but I think that having a way to opt out of any magic-ness it will go a long way towards making --remote-name suitable for scripting.
|
|
||
| With no argument, creates a fork of the current repository. Otherwise, forks the specified repository. | ||
|
|
||
| By default, the new fork is set to be your 'origin' remote and any existing origin remote is renamed to 'upstream'. To alter this behavior, you can set a name for the new fork's remote with --remote-name. |
There was a problem hiding this comment.
Our help docs currently have lines hard-wrapped to 80 columns, so maybe this line should wrap too. #1469
| return err | ||
| } | ||
| renameTarget := "upstream" | ||
| renameCmd, err := git.GitCommand("remote", "rename", remoteName, renameTarget) |
There was a problem hiding this comment.
I'm guessing the only way for remoteName to be blank is if the user passed --remote-name="", and in that case I expect that the command should fail since that isn't a valid value.
|
I've:
|
3 participants
This fully restores the fork remote renaming behavior altered originally in #1882 but leaves the
--remote-nameflag intact; it also adds a note about this behavior to theforklongform help.Closes #2904