Skip PR/issue creation prompt completely & open the editor instead

[ahmedelgabri]

Describe the feature or problem you’d like to solve

I prefer hub behavior of creating PRs, which open the editor directly to fill in everything (title & body). I'd like to have a way to skip all the prompts if possible with gh. I'm aware that the prompt is mainly needed to be able to preview the PR later before submission but that's something I rarely need or use, it also reduces friction & allows you to edit your PR title easier if you change your mind or had a typo.

Proposed solution

Add a --skip-prompt or maybe --editor flag to skip the prompt

---

Edit: this also applies to gh issue create

[francois]

Yup, this is something very important for me. We discussed this in #216.

[waldyrious]

I'd like this behavior to be configurable, if implemented. The interactive prompts can be more friendly for beginners.

[rufuspollock]

+1 and it would be important for me that i could set this as the default behaviour - I don't want to have to add an extra flag every time i open an issue etc. (And thanks for all the work on this and hub!)

[mislav]

Thanks for everyone's patience! We've just discussed this and given it a green light to proceed:

• These commands should gain an --editor flag, like issue comment already has:
  • issue create
  • issue edit
  • pr create
  • pr edit
• The first line from editor text is the title and rest is taken as body.
• All other prompts should be skipped in this mode.
• Since there are now no prompts, an issue/PR template should be selectable using a new flag: Enable specifying which issue template to use when creating #1553
• For PRs, since there is now no prompt to choose a push destination, the user will have to git push before invoking gh pr create --editor. Would there be a better way we could handle this?
• If --fill was also used for PRs, open the editor with the pre-filled contents that would normally be submitted without the --editor flag. If one exists, the PR template contents should also be added so it's available for editing. Ref. Unwrap commit message body when using gh pr create --fill #1446

Then, in the future, we can separately consider adding --editor to other commands too where we currently prompt for title & body, like in release create.

Ref. #535

[Duologic]

• For PRs, since there is now no prompt to choose a push destination, the user will have to git push before invoking gh pr create --editor. Would there be a better way we could handle this?

hub has flags: -p for push and -d for draft, which I use often.

[jglick]

If --fill was also used for PRs, open the editor with the pre-filled contents…

Would like a fully automatic mode that would allow --fill (or --body + --title) to immediately push the branch and file the PR with no prompts.

[sozoalvin]

just chanced upon this PR - since hub CLI achieved the same - would it be better to continue using hub for people who liked this functionality? (creating PR via editor without prompt)

[robinbowes]

I'm curious why it has taken four years to not do anything about this frequently-requested functionality?

Any new tickets that are raised requesting the same functionality are closed in favour of this one, and yet here we are - no progress.

We even had a pull request providing the functionality, but it languished without review for so long that both DRIs left the project/company.

It seems this issue is now blocked by a consideration being given to batch a whole bunch of changes into a new major release: another issue: #7575

However, it seems no-one is assigned to that issue and it has not seen any updates for > 3 months.

https://github.com/samcoe

@samcoe Can you give us any update on the situation?

[williammartin]

Hey @robinbowes, @samcoe also left the company around the time you posted your comment and neither Andy or I were on this thread, I just happened across your comment while doing some triaging.

I can't speak for anything before my tenure on the team which is less than a year. The challenge that we currently face is that the previous maintainers, having been on the team since the beginning, had built up a large collection of ideas for changes in #7575 and then they all left GitHub. Although we are hiring into the team, @andyfeller and myself do not have the capacity to tackle #7575 right now.

That said, my communication on #7193 was largely driven by the previous maintainers' desire to block changes and revisit those commands holistically. We're now a different team with different context, capabilities and priorities. Given that we are unlikely to get around to addressing #7575 any time soon, I'm open to revisiting #7193 independently of that decision.