When a repository argument is provided to `gh repo fork`, the command
operates independently of the current local repository. Using --remote
in this context is incompatible because there's no local repository to
add the remote to.
This change returns an explicit error when these flags are combined,
providing clear feedback instead of silently ignoring the --remote flag.
Fixes#2722
Signed-off-by: majiayu000 <1835304752@qq.com>
When running `gh repo fork` in the context of an existing repo, the CLI offers to create a remote for the fork:
```
? Would you like to add a remote for the fork? Yes
```
If you accept, it prints a log stating that the `origin` remote has been created:
```
✓ Added remote origin
```
Where there is an existing `origin` remote, this is renamed to `upstream`, but this is done silently without any notification to the user.
```bash
$ git remote -v
origin https://github.com/timrogers/badger.github.io.git (fetch)
origin https://github.com/timrogers/badger.github.io.git (push)
upstream https://github.com/badger/badger.github.io.git (fetch)
upstream https://github.com/badger/badger.github.io.git (push)
```
It seems kinda fine to rename the remote without explicitly confirming since this is not a truly destructive action, but it should make it clear what it is doing.
This updates the logging to explicitly log about the renaming of
the existing remote:
```
✓ Renamed remote origin to upstream
```
Fixes#9982.
A new GitHub feature landed where the API client can specify the desired
name of the new fork. This avoids the necessity of subsequently having
to rename the forked repo after the fork operation has created one.
For backwards compatibility, the renaming logic is still here, but
activates only if the resulting repo name is not the desired name.
