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: https://github.com/cli/cli/issues/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. https://github.com/cli/cli/issues/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. https://github.com/cli/cli/issues/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: https://github.com/cli/cli/issues/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.

[andyfeller]

@robinbowes @notomo @ahmedelgabri @francois @waldyrious : reviewing the #7193 PR, I wanted to pull some of the questions out of the PR and back here to understand exactly what this experience might look like.

• Should the editor support similar git commit experience emitting clean up hint that is cleaned up (implementation) after exiting?

  _
  # Please enter the commit message for your changes. Lines starting
  # with '#' will be ignored, and an empty message aborts the commit.
  #
  # On branch main
  # Your branch is up to date with 'origin/main'.
  #
  # Changes to be committed:
  #   new file:   promote-release.sh
  #
  # Untracked files:
  #   whatever
  #
  

  The git commit experience is the best I can think to imitate so as not to leave the user guessing what comes next.

• should users be able to exit without creating an issue or PR? for example, exit with an empty message to cancel

• what should gh issue create emit once the editor is closed?

  • should we show title, body, and/or both?
  • emit a confirmation prompt?
  • what about other metadata? (assignees, labels, projects, milestone)

• what kind of configuration option could be added to default to --editor experience without having to provide the flag? should there be separate flags for gh issue create vs gh pr create

[notomo]

Thanks for listing discussion points! The followings are my opinion.

Should the editor support similar git commit experience emitting clean up hint that is cleaned up after exiting?

It sounds good and friendly. I image to use html comment with some marks.

<!-- (gh)
hint message
(gh) -->

(Though I don't know whether it's required in the first implementation)

should users be able to exit without creating an issue or PR? for example, exit with an empty message to cancel

I think it's sufficient raising an error when it cannot be created, like gh issue comment --editor.

$ gh issue comment --editor 1
GraphQL: Body cannot be blank (addComment)

Also, some text editor have the way to exit with specific error code. For example vim's :cquit.

what should gh issue create emit once the editor is closed?

I don't expect any prompts and title, body, since I think --editor experience is similar to using --title and --body. Personally, I'd like to use issue/PR template and frontmatter if supporting metadata.

what kind of configuration option could be added to default to --editor experience without having to provide the flag? should there be separate flags for gh issue create vs gh pr create

Hmm, I have no idea with config.

[ahmedelgabri]

@andyfeller I mostly agree with @notomo but I have some minor differences

should users be able to exit without creating an issue or PR? for example, exit with an empty message to cancel

I think it's sufficient raising an error when it cannot be created, like gh issue comment --editor.

$ gh issue comment --editor 1
GraphQL: Body cannot be blank (addComment)

I think this is too verbose, especially if I'm exiting the editor with something like :cquit I think a more friendly error could be something along these lines

Aborting creating a pull-request/issue/comment

Unless it's a real error then yeah showing that is better.

what should gh issue create emit once the editor is closed?

I don't expect any prompts and title, body, since I think --editor experience is similar to using --title and --body. Personally, I'd like to use issue/PR template and frontmatter if supporting metadata.

I'm fine with just printing the PR/Issue/Comment URL

what kind of configuration option could be added to default to --editor experience without having to provide the flag?

My first idea was maybe something like skip_prompt but I see here there is already a prompt: boolean config, would it be possible to use this?

• true (default): enable prompts (CLI --editor flag should override this)
• false: disable prompts

should there be separate flags for gh issue create vs gh pr create

No, I think it should be the same flag for both (or any command that might need this workflow)

[andyfeller]

@notomo @ahmedelgabri : thank you both for the follow up! 🤗 I'm 80% in agreement with the ideas raised with the only area of concern being configuration aspect.

Exiting without creating an issue / PR

should users be able to exit without creating an issue or PR? for example, exit with an empty message to cancel

I think it's sufficient raising an error when it cannot be created, like gh issue comment --editor.

$ gh issue comment --editor 1
GraphQL: Body cannot be blank (addComment)

I think this is too verbose, especially if I'm exiting the editor with something like :cquit I think a more friendly error could be something along these lines

Aborting creating a pull-request/issue/comment

Unless it's a real error then yeah showing that is better.

👍 I think this exit message is more appropriate

Post-editing experience

what should gh issue create emit once the editor is closed?

I don't expect any prompts and title, body, since I think --editor experience is similar to using --title and --body. Personally, I'd like to use issue/PR template and frontmatter if supporting metadata.

I'm fine with just printing the PR/Issue/Comment URL

👍 This is a fair and consistent call out

Configuration

should there be separate flags for gh issue create vs gh pr create

No, I think it should be the same flag for both (or any command that might need this workflow)

Re-reading this, let me clarify what I intended to ask: should there be separate gh config values for gh issue create vs gh pr create? In other words, are users wanting editor experience all or nothing?

I imagine initially making it all or nothing then separate if/when feedback pops up makes sense.

what kind of configuration option could be added to default to --editor experience without having to provide the flag?

My first idea was maybe something like skip_prompt but I see here there is already a prompt: boolean config, would it be possible to use this?

• true (default): enable prompts (CLI --editor flag should override this)
• false: disable prompts

My knee jerk thought 🤔 is keeping existing configuration value behaviors as-is and having a separate configuration value. The editor experience being discussed here is really just a different type of prompt that is customized by editor configuration value. I don't think everyone would assume the editor experience by default.

What do you think about:

- `prefer_editor_prompt`: toggle preference for editor-based interactive prompting in the terminal {enabled|disabled} (default disabled)

[ahmedelgabri]

I imagine initially making it all or nothing then separate if/when feedback pops up makes sense.

Yeah, makes sense

My knee jerk thought 🤔 is keeping existing configuration value behaviors as-is and having a separate configuration value. The editor experience being discussed here is really just a different type of prompt that is customized by editor configuration value. I don't think everyone would assume the editor experience by default.

What do you think about:

- `prefer_editor_prompt`: toggle preference for editor-based interactive prompting in the terminal {enabled|disabled} (default disabled)

Fine by me too, I'm just a bit allergic to the explosion of options/settings. But you folks know more here than I do.

[andyfeller]

I image to use html comment with some marks.

<!-- (gh)
hint message
(gh) -->

(Though I don't know whether it's required in the first implementation)

I'm open to ideas; I think the main question is how reliable of removing the comments will be. 🤷

Originally, I was thinking of how git commit works strictly because it was the only similar experience I could recall. That said, git doesn't have to deal with markdown such as headers beginning with # which is kind of the point of markdown much less issue and PR bodies.

With all of that said, I think we have talked about the biggest concerns that come to mind.

[ahmedelgabri]

That said, git doesn't have to deal with markdown such as headers beginning with # which is kind of the point of markdown much less issue and PR bodies.

I don't even think that gh should care about this, it should respect what's set in core.commentchar and that's it, no?

[andyfeller]

That said, git doesn't have to deal with markdown such as headers beginning with # which is kind of the point of markdown much less issue and PR bodies.

I don't even think that gh should care about this, it should respect what's set in core.commentchar and that's it, no?

I think there is a little confusion, let me try to clarify:

• I was drawing inspiration from git commit experience for gh issue create / gh pr create discussion which defaults to using # for comments
• gh definitely doesn't care about how git commit works and defers to users' git config preferences when we invoke git externally
• gh issue create --editor does care about Markdown and # is meaningful to Markdown
• beyond @notomo idea of leaving user guidance in the form of HTML comments, I was wondering if some other character could be use to simulate git commit like comments like maybe ; that can be more reliably stripped out after closing the gh issue create --editor experience

So something like:

; Please enter the title and body for your issue, separated by
; an empty line. Lines starting with ';' will be ignored, and an
; empty message aborts the creation process.
;
; On repo cli/cli

[joeshaw]

hub used to insert a line below which everything was ignored. https://github.com/mislav/hub/blob/master/github/editor.go#L18 and https://github.com/mislav/hub/blob/master/github/editor.go#L59-L69

It makes for a good demarcation point and avoids the need to bother with choosing a comment character or parsing every line.

The other nice thing is that it makes it relatively straightforward to append things to this file (like the commit messages of the commits in the PR) without needing to do any special handling. This is another feature from hub that I miss. See https://github.com/cli/cli/issues/8018.

[notomo]

The advantage of using html comments is that it is supported by markdown syntax highlighting. But I'm not too particular about this method.

hub used to insert a line below which everything was ignored.

It make sense.

[andyfeller]

hub used to insert a line below which everything was ignored. https://github.com/mislav/hub/blob/master/github/editor.go#L18 and https://github.com/mislav/hub/blob/master/github/editor.go#L59-L69

It makes for a good demarcation point and avoids the need to bother with choosing a comment character or parsing every line.

TIL! I appreciate this novel approach ❤ Wanting to ensure there's some room for experimentation, I think there's enough ideas to provide guidance on the work.

With all of that being said, I think theres enough context to unblock any contribution:

1. New gh config value that users can enable that would prefer editor experience where applicable
2. New editor experience to gh issue create triggered by new --editor flag or new gh config value
3. New editor experience to gh pr create triggered by new --editor flag or new gh config value
4. Editor experience having some way to capture instruction that can be ignored upon submission
5. Editor experience having some way to cancel creation through empty message
6. Editor experience resulting in a web link to the resulting issue or PR

Is there anything else missing?

[andyfeller]

With #7193 focused on gh issue create --editor, I've split off the PR experience into https://github.com/cli/cli/issues/9310 so we can avoid dragging out this issue and the related PR. 👍