Skip to content

Add preliminary repo create command - #547

Merged
mislav merged 9 commits into
masterfrom
repo-create
Mar 3, 2020
Merged

Add preliminary repo create command#547
mislav merged 9 commits into
masterfrom
repo-create

Conversation

@mislav

@mislav mislav commented Feb 25, 2020

Copy link
Copy Markdown
Contributor
Create a new GitHub repository.

Usage:
  gh repo create [<name>] [flags]

Flags:
      --public   Make the new repository public

Global Flags:
      --help              Show help for command
  -R, --repo OWNER/REPO   Select another repository using the OWNER/REPO format

TODO:

  • Add a git remote for the new repo
  • Add ability to specify the org owner for the repo
    • Add ability to specify org team that should be granted access
  • Set description, homepage fields
  • Add flag for hasIssuesEnabled?
  • Add flag for hasWikiEnabled?

Discuss:

  • If the name for the repo wasn't given, the top-level project directory name is used instead. Is this a good default?
  • Should we automatically add a git remote for the new repository upon successful repo create?
  • What should happen if repo create was run in a context outside of a local git repository?
  • If we allow specifying an organization + team for the new repo, what should the interface for that look like?
  • Should we support disabling issues/wiki in the new repo?
  • Should we support creating repositories from template repos? If so, how would that usage differ from regular usage?

Fixes #300

@vilmibm

vilmibm commented Feb 25, 2020

Copy link
Copy Markdown
Contributor

If the name for the repo wasn't given, the top-level project directory name is used instead. Is this a good default?

I like this.

Should we automatically add a git remote for the new repository upon successful repo create?

My gut says no; I'm not sure when this would be useful?

What should happen if repo create was run in a context outside of a local git repository?

User is asked if they'd like to clone the repo (like what I'm doing in #549).

If we allow specifying an organization + team for the new repo, what should the interface for that look like?

Org seems like it could be specified by passing the repo name explicitly in the form OWNER/REPO. Teams I think would have to be a string slice argument of team names?

Should we allow disabling issues/wiki in the new repo?

I like the idea of having flags for this but it could also be follow up work.

@mislav

mislav commented Feb 25, 2020

Copy link
Copy Markdown
Contributor Author

Should we automatically add a git remote for the new repository upon successful repo create?

My gut says no; I'm not sure when this would be useful?

# in a new project:
git init
# add some commits...
gh repo create
git push -u origin master

User is asked if they'd like to clone the repo

A new GitHub repository is empty; there is nothing to clone 🤔

@vilmibm

vilmibm commented Feb 25, 2020

Copy link
Copy Markdown
Contributor

@mislav i don't know why i didn't think of the new project case 🤦‍♀️ i do think we should automatically add a remote, yes.

A new GitHub repository is empty; there is nothing to clone

wouldn't a directory with a .git be set up so they can start committing? or am i misunderstanding?

@vilmibm vilmibm mentioned this pull request Feb 26, 2020
@ampinsk

ampinsk commented Feb 26, 2020

Copy link
Copy Markdown

If the name for the repo wasn't given, the top-level project directory name is used instead. Is this a good default?

Yes, totally reasonable!

Should we automatically add a git remote for the new repository upon successful repo create?

I am leaning towards yes here

What should happen if repo create was run in a context outside of a local git repository?

I kind of like the idea of us running git init if they haven't yet, but I think that's really risky. It's probably safest to error for now.

If we allow specifying an organization + team for the new repo, what should the interface for that look like?

Agree that this seems implicit in passing OWNER/REPO? I might not understand the case you're talking about fully.

Should we support disabling issues/wiki in the new repo?
Should we support creating repositories from template repos? If so, how would that usage differ from regular usage?

I think these can both be follow up items 👍

@mislav

mislav commented Feb 26, 2020

Copy link
Copy Markdown
Contributor Author

Added support for more repository fields:

Create a new GitHub repository.

Usage:
  gh repo create [<name>] [flags]

Flags:
  -d, --description string   Description of repository
      --enable-issues        Enable issues in the new repository (default true)
      --enable-wiki          Enable wiki in the new repository (default true)
  -h, --homepage string      Repository home page URL
      --public               Make the new repository public

To complete this PR, working on organization repo support and covering the case of this command being run outside of the context of an existing git repository.

@mislav
mislav marked this pull request as ready for review March 3, 2020 20:50
@mislav

mislav commented Mar 3, 2020

Copy link
Copy Markdown
Contributor Author

Added support for orgs:

Create a new GitHub repository.

Use the "ORG/NAME" syntax to create a repository within your organization.

Usage:
  gh repo create [<name>] [flags]

Flags:
  -d, --description string   Description of repository
      --enable-issues        Enable issues in the new repository (default true)
      --enable-wiki          Enable wiki in the new repository (default true)
  -h, --homepage string      Repository home page URL
      --public               Make the new repository public
  -t, --team string          The name of the organization team to be granted access

Global Flags:
      --help              Show help for command
  -R, --repo OWNER/REPO   Select another repository using the OWNER/REPO format

API v3 is used due to GraphQL equivalents needing additional read:org OAuth scope to resolve org/team names to GraphQL node IDs.

Additionally, when this command is ran from outside of a git repo, it prompts to set up a new git directory for the new GitHub repo.

@mislav
mislav requested a review from vilmibm March 3, 2020 20:53

@vilmibm vilmibm left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is definitely follow up work I want to see but there's nothing I'm not comfortable with us shipping as it is.

Comment thread command/repo.go
isTTY = utils.IsTerminal(outFile)
if isTTY {
// FIXME: duplicates colorableOut
out = utils.NewColorable(outFile)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do want to see this cleaned up and better abstracted but am ok with that being follow-up work

Comment thread command/repo.go Outdated
}
} else if isTTY {
doSetup := false
// TODO: use overridable Confirm

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

given that i added that in repo fork i'm ok with follow-up work increasing test coverage one all the repo stuff is in.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's what the TODO work is all about. Furthermore, I only activate prompts if stdout is a tty (come to think of it, we should also check if stdin is tty, otherwise prompts won't work), and currently we don't have a way of emulating a tty in tests.

@mislav
mislav merged commit 6c2328b into master Mar 3, 2020
@mislav
mislav deleted the repo-create branch March 3, 2020 22:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add create repository command

3 participants