This adds the missing mocked http tests to the http_test.go file. These
tests were previously bundled with the tests in list_test.go, creating a
testing pattern that was difficult to understand and maintain. The
refactor in the previous commit replaced these tests with the
AutolinkClient interface, allowing for the httpmocks to be isolated to the
AutolinkGetter that implements that interface.
This defines an AutolinkClient interface with a Get method used for
fetching the autolinks lists from the api. Then, the http client for
autolinks implements this interface with the AutolinkGetter struct.
This allows for dependency injection of the AutolinkGetter struct into the
listOptions, enabling mocking of the AutolinkGetter for testing. The
result of this is simpler tests that are easier to maintain, because the
interface for the table tests now allow for defining autolink structs as
the response instead of large mocked api calls.
This also allows for bespoke testing of the http file, which I'll follow
up with in the next commit.
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
