-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add preliminary repo create
command
#547
Conversation
I like this.
My gut says no; I'm not sure when this would be useful?
User is asked if they'd like to clone the repo (like what I'm doing in #549).
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?
I like the idea of having flags for this but it could also be follow up work. |
# in a new project:
git init
# add some commits...
gh repo create
git push -u origin master
A new GitHub repository is empty; there is nothing to clone 🤔 |
@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.
wouldn't a directory with a |
Yes, totally reasonable!
I am leaning towards yes here
I kind of like the idea of us running
Agree that this seems implicit in passing OWNER/REPO? I might not understand the case you're talking about fully.
I think these can both be follow up items 👍 |
Added support for more repository fields:
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. |
Added support for orgs:
API v3 is used due to GraphQL equivalents needing additional 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. |
There was a problem hiding this comment.
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.
isTTY = utils.IsTerminal(outFile) | ||
if isTTY { | ||
// FIXME: duplicates colorableOut | ||
out = utils.NewColorable(outFile) |
There was a problem hiding this comment.
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
command/repo.go
Outdated
} | ||
} else if isTTY { | ||
doSetup := false | ||
// TODO: use overridable Confirm |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
TODO:
hasIssuesEnabled
?hasWikiEnabled
?Discuss:
repo create
?repo create
was run in a context outside of a local git repository?Fixes #300