oops, meant to comment instead of comment-review.

I'll do a complete review later today or tomorrow.

Thank you for taking this on! Unfortunately, as it stands, this PR presents too great a risk for our users. This was discussed in the original issue; consider these two scenarios:

scenario 1: empty local repo

• mkdir foo; cd foo; git init
• gh repo create # adding a license or ignore
• git pull origin main

This puts you in a happy state where your local branch matches the remote and you are free to add commits.

scenario 2: non-empty local repo

• mkdir foo; cd foo; git init
• echo "foo" > foo.txt; git add foo.txt; git commit -m'foo'
• gh repo create # adding license/ignore
• git pull origin main # results in fatal: refusing to merge unrelated histories
• git push origin main # results in rejected push

This puts you in a broken state that requires git knowledge to correct.

Scenario 2 is totally unacceptable from our perspective; many users will be confused and frustrated by this and it's very easy to make it happen. Without a remediation plan for scenario 2, this PR won't be able to move forward.

Unfortunately, I can't think of any strategies around this given what tools the API currently exposes. The safest thing is to ensure that changes like this -- adding an ignore or a license -- start as a local commit that get pushed. However, that would require duplicating .com functionality (ie actually getting templates and rendering them) which is non-trivial effort and may end up being brittle.

One path forward here might be only exposing gitignore/license generation for the gh repo create REPONAME case. Right now we treat that as a separate code path (for historical reasons I can't entirely remember) that is still interactive but has different questions. In that case, we're creating a repo from scratch and then optionally cloning it: It's entirely safe to add ignore/license in that mode. I'm open to this PR being retooled for that.

oof, this is not on you, but I realized in testing that gh repo create foo needs some additional tweaking to make this work.

Currently, it creates the repo on GitHub and then creates a new local repo, but it doesn't yet know what the default branch and can't actually mirror the content locally.

The core issue here is that there is some lag between creating the repo on GitHub and it actually being clone'able.

If you're up for it, I think the next step would be experimenting with a for loop with an interval and timeout for blocking the command until the repo exists then doing a clone (instead of localInit).

Nice work :D