- this was something I did in the original implementation of this improved extension update notification logic
- discovering other parts of the extension manager code that were working with non-prefixed extension names motivated a different approach
- the extension manager code that requires the extension be prefixed has been enhanced to use the centralized ensurePrefixed() logic, making the need for this on the extension unnecessary
- extension manager has been made responsible for extension update directory information
- extension manager has been enhanced to ensure that previously left extension update metadata is deleted before installing an extension
- extension manager has been enhanced to ensure that extension update metadata is deleted when extension is being removed
- refactored extension command tests for manager change, ensuring previous and expected states along with returned release info
- refactored extension manager tests for ensuring previous extension update entries are removed before installing extension
- created extension manager test for installing local extension
- centralized logic for checking and ensuring extension name is "gh-" prefixed
Closes#10013
This commit enhances `gh pr checks` to exit with an error when mutually exclusive `--json` and `--watch` flags are used. Users are encouraged to either 1) retrieve information about the checks via `--json` or 2) watch and wait on PR checks that are being updated.
First pass at implementing basic test around extension state checking behavior, wanting to discus with team about level of testing to perform and whether this is really the right place.
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.
