this adds recognition of the git_protocol setting when:
- creating a repo
- cloning a repo
- forking a repo
- forking/pushing during pr create
- checking out a PR
additionally, it:
- consolidates remote adding to use AddRemote; this introduces a fetch
where there previously hadn't been one
- changes repo clone to accept an ssh url
- changes repo fork to accept an ssh url
i just added basic unit tests; adding new test cases for all of the
above scenarios seemed like diminishing returns.
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.
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.
If multiple templates are found, the user is prompted to select one.
The templates are searched for, in order of preference:
- issues:
1. `.github/ISSUE_TEMPLATE/*.md`
2. `.github/ISSUE_TEMPLATE.md`
3. `ISSUE_TEMPLATE/*.md`
4. `ISSUE_TEMPLATE.md`
5. `docs/ISSUE_TEMPLATE/*.md`
6. `docs/ISSUE_TEMPLATE.md`
- pull requests:
1. `.github/PULL_REQUEST_TEMPLATE/*.md`
2. `.github/PULL_REQUEST_TEMPLATE.md`
3. `PULL_REQUEST_TEMPLATE/*.md`
4. `PULL_REQUEST_TEMPLATE.md`
5. `docs/PULL_REQUEST_TEMPLATE/*.md`
6. `docs/PULL_REQUEST_TEMPLATE.md`
The filename matches are case-insensitive.
