gh repo create redux

This issue covers a complete overhauling of gh repo create, a command that is saturated with technical debt and bugs.

Our intention is to rethink the UX of creating repositories with gh, streamlining it and making it more consistent than what exists today. In the process, we'll either outright fix or at least lay the groundwork for fixing the collection of improvements listed in #2184 .

@vilmibm will be the UX resource and general advisor; @pxrth9 and @meiji163 will be dividing up the work as they see fit.

General notes

• if using the default host, GitHub should be used. Otherwise (ie for an enterprise host), print the actual hostname
• because it introduces too many complications, adding .gitignore and license files to existing local repositories is not supported.
• git output should be suppressed by default
• making a new repo in a directory that is a subdirectory of an existing git repo should Just Work
• usage docs should be overhauled to match new stuff

No arguments (interactive usage)

No arguments; in a git repository

$ cd mycode
$ gh repo create
? Which would you like to do?
  Create a new repository on GitHub from scratch
> Push an existing local repository to GitHub 
? Path to local repository? (.)
? Repository name (mycode)
? Description a test repo
? Visibility
> Public
  Private
  Internal
✓ Created repository vilmibm/mycode on GitHub
? Add a remote? (Y/n) y
? What should the new remote be called? (origin) upstream
✓ Added remote "upstream" for https://github.com/vilmibm/mycode.git
? Would you like to push local commits on "trunk" and track "upstream"? (Y/n) y
✓ "trunk" now tracking "upstream/trunk"
✓ local commits pushed

No arguments; not in a git repo locally

$ gh repo create
? Which would you like to do?
> Create a new repository on GitHub from scratch
   Push an existing local repository to GitHub 

? Name mycode
? Description a test repo
? Visibility
> Public
  Private
  Internal
? Would you like to add a .gitIgnore (y/N) n
? Would you like to add a license? (y/N) n
? Going to create vilmibm/mycode as a public repository on GitHub. Continue? (Y/n) y
✓ Created repository
? Clone the new repository locally? (Y/n)
✓ Initialized repository in "mycode"

Arguments (non-interactive)

If any argument is passed:

• no interactivity
• name and visibility (one of --private, --public, --internal) required at a minimum
• assumes desire is to create a new repo on a github host unless --source is passed

$ gh repo create mycode
Command requires one of: --public, --private, or --internal
$ gh repo create mycode --private
https://github.com/vilmibm/mycode

New arguments

• --source specifies path to existing local repository that should be pushed to a github host; for example, gh repo create --source=.
  • mutually exclusive with --gitignore and --license and --template and --clone
  • should error if path is not a local git repo
• --remote specify a remote name to use when mirroring on github host; for example, gh repo create --source=. --remote=upstream
  • only works with --source
• --push runs git push -u $remote $currentbranch
  • only works with --source
• --clone clones the repository to the current directory
  • mutually exclusive with --source and --remote
• --disable-issues
• --disable-wiki

Deprecated arguments

These should be hidden from usage but still supported.

• --confirm is no longer needed; presence of any argument avoids interactivity
• --enable-issues replaced with disable-issues
• --enable-wiki replaced with disable-wiki

Unchanged arguments

• --homepage
• --team
• --description
• --private
• --public
• --internal
• --license
• --gitignore
• --homepage
• --template

Addenda

Mislav also wrote up notes for this; I've tried to incorporate them all but wanted to include them verbatim for reference.

Main problems:

• gh repo create does different things depending on whether you are in a local git repo: this can be surprising/confusing/limiting for the user.
  • As a result, you are not allowed to create a new repo in a subdirectory of the current local git repository. An attempt to do so will likely result in a error: remote origin already exists.
• gh repo create doesn't allow you to just create a GitHub repository and do nothing else (no cloning the new repo, no adding a new remote).
• Pushing local commits to a just-created repository isn't easy: Add a way for gh repo create to push the HEAD branch #3209. Currently it involves knowing to run a command like git push --set-upstream origin HEAD. We could allow users to opt into auto-pushing the local code to the new repository via an opt-in flag like --push.

Limiting factors: a lot of people use gh repo create already and we should avoid breaking its existing usages and behaviors, particularly non-interactive ones. We are free to tweak the interactive flow and to add new flags, though.

Potential approach: allowing the user to specify exactly what they want with gh repo create, instead of us having to guess their intention and the context. For example, if they want to create a repo and add it as a local git remote, maybe we can allow them to explicitly say that via a --add-remote=origin flag (that would also let them pick the name for the remote). The interactive flow could also do a better job of asking them for their intentions. Generally, less "magic", more explicitness is always better for CLIs.