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.
Refactor the logic for checking `workflow` scope checking in releases to be in the positive - check if the scope is there, not check if it isn't there. Then, when the function is called we invert it.
Also update comments to be more imperative.
This refactor also incorporates @andyfeller's suggestion to use `slices`.
Co-Authored-By: Andy Feller <andyfeller@github.com>
This commit expands filepathDescendsFrom(string, string) to handle edge cases such as mixing absolute and relative paths or artifact name edge cases.
Additionally, tests for filepathDescendsFrom() and downloadrun() have been expanded to verify additional use cases.
This incorporates the work done by @williammartin to improve reasoning about `gh run download` behavior through testing while verifying a simpler solution to checking if a path is contained within a directory.
This builds off suggestion to reuse logic used already within `gh run download` for detecting path traversals.
This largely works but runs into an issue where detection logic doesn't handle non-separated traversal.
You need to know exact `baseRefOid` so you could show correct diff.
`baseRefName` is not enough sometimes because branch from which PR was
forked might have changes already.
Example usage:
```
gh pr view --json headRefName,headRefOid,number,baseRefName,baseRefOid,reviewDecision
```
