The "STALE" conclusion has shipped this January and is basically a
conclusion that can only be reported by GitHub and not explicitly set by
any integrations.
A branch is considered already pushed if its HEAD commit hash matches
the commit hash of one of the remote tracking branches:
`refs/remotes/<remote>/<branch>`
This mechanism allows the user to:
- Choose a remote as push target for their branch different than the one
that would automatically get chosen for them by `pr create`;
- Avoid a `git push` operation (and its associated git hooks) if a push
was not necessary in the first place.
A valid remote specificication read from `branch.<name>.remote` git
config can be a URL, a `.`, a filesystem path, and a remote name. When
detecting the remote name, be sure not to take filesystem paths instead.
This API was just fixed in github.com, but it will take a while for the
change to propagate to GitHub Enterprise installs, so guard ourselves
from false positives when querying forks.
Explicitly assign the writer stream for the progress spinner so that
tests may override it.
The default when not in testing stays the same: the output stream is the
colorable stdout.
Previously, the repository owner+name component of the URL was ignored
and only the pull request number was read. Now, the URL dictates which
base repository will be used.
The 2nd argument now unused since we've determined that, in practice, we
can safely fetch git objects from a freshly created fork on GitHub and
that we don't need the remote URL-swapping workaround.
Before: the default push target for the current branch in `pr create`
was the first repository found among git remotes that has write access.
Now: the default push target is the fork the base repo, if said fork
exists and has write access, falling back to old behavior otherwise.
This change in the default is to facilitate contributions to projects
that have a hard requirement that all pull requests (even those opened
by people with write access to that project) come from forks.
