use_github(): be more resilient to partial setup #221
Comments
|
Feeling shame because I should have thought to file this issue |
jennybc
changed the title
|
Could one also set push to FALSE, exposing a |
hadley
added a commit
that referenced
this issue
Nov 28, 2018
Now checks individual for origin remote (i.e. is there a GitHub repo), description fields, and push-ability for master. Fixes #221
hadley
added a commit
that referenced
this issue
Jan 23, 2019
* Break use_github flow into smaller pieces Now checks individual for origin remote (i.e. is there a GitHub repo), description fields, and push-ability for master. Fixes #221 * Be consistent with create_from_github(), use_tidy_thanks() We're trying to standardize on "repo_spec" to refer to a "owner/repo" combination * Open repo in browser after we (hopefully) have pushed * Add more tips for getting the git situation sorted out for use_github() * Remove `base_path` and `path` arguments from git and github helpers * Consistent approach to multi-line ui_stop() * More consistent if {} else {} style
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now it is possible for
use_github()to successfully create a GitHub repo and set a remote. But then fail to push, e.g. due to SSH key/passphrase problems.Then, when you call it again, it exits early, because it thinks the repo already uses GitHub, because the remote is set. If you unset that, you get a new (cryptic) error because the remote repo already exists.
Could it handle "partial setup" better?
The text was updated successfully, but these errors were encountered: