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.
This commit modifies interactive and non-interactive behaviors around `gh repo edit` as well as providing greater information about the impact.
1. `--help` usage is expanded to highlight the most significant consequences of changing visibility
1. `--help` usage and interactive experience call out GitHub Docs content that act as source of truth about full consequences of various changes
1. `gh repo edit` interactive experience will require confirmation for any visibility change
1. `gh repo edit` interactive experience will output potential stars and watchers lose regardless of visibility transition
1. `gh repo edit` will require `--visibility` flag to include new `--accept-visibility-change-consequences` flag regardless of interactivity
Relates #8946
- updates the documentation within `gh repo create` to include links to lookup .gitignore templates and licenses
- fixes link markup within `gh auth setup-git` so link is formatted correctly on https://cli.github.com
