Repository navigation
gh pr create --web does not respect title and body arguments #10527
Description
with gh pr create --fill --title "test" --body "ticket number" the title and body options take precedence and overwrite any autofilled content as stated in the docs:
It's important to notice that if the `--title` and/or `--body` are also provided
alongside `--fill`, the values specified by `--title` and/or `--body` will
take precedence and overwrite any autofilled content
however, this does not seem to be the case when using the --web flag as well: gh pr create --fill --title "test" --body "ticket number" --web. this does not prioritise the title and body options..
Affected version
2.67.0 (2025-02-11)
Steps to reproduce the behavior
gh pr create --fill --title "test" --body "ticket number" --web- See image
Expected vs actual behavior
Expected: gh pr create --assignee @me --fill --title "test" --body "ticket number" --web should prioritise the title and body options with the web flag as well
Activity
jtmcg commentedon Mar 3, 2025
Interesting find, @simon-isler. I've confirmed I'm seeing the same behavior. In particular, it looks like these get populated by the query params in the url when we open the page. Specifically, this bit looks suspect:
(edit: don't know why this isn't embedding a preview)
https://github.com/cli/cli/blob/5e21f6ac17e4eda480258d6c370987582a22ee9b/pkg/cmd/pr/create/create.go#L282C30-L285
Acceptance Criteria
Given I have a branch any number of commits
when I use
gh pr create --web --fillwith--title "<title>"and/or--body "<body>"then the PR on the web browser is pre-filled with the title and body provided in the command and NOT the default behavior of the
--fillflagsislr commentedon Mar 4, 2025
thanks @jtmcg! looking forward to investigate this
andyfeller commentedon Jul 14, 2025
Reopening this issue as #10547 was reverted due to regression in #11277 with preliminary notes captured in #11277 (comment)
babakks commentedon Aug 7, 2025
TL;DR
Due to complexity of the
pr createcommand implementation and that the initial fix for this issue (PR #10547) caused a regression (#11277), we decided to follow a more resilient approach toward fixing this. That's why I've closed my new PR on this (#11306).Over an internal discussion with @andyfeller and @BagToad, we decided to fix this issue in two steps:
First step: fixing the issue with a minimum set of changes, but with the addition of necessary acceptance tests.
Second step: refactoring the logic in the
NewIssueStatefunction toward a better readable, less-side-effect implementation. In other words it's to pay the tech debt.Since the first step explained above actually fixes the issue, we don't need another issue for it. I'll write down the A/C in another comment.
Effect of various
gh pr createin--webmodeWe're now talking about the
--webmode operation, not the interactive/non-interactive flows.To have a clear understanding of what is the expected behaviour we need to lay out an exhaustive list of possible combinations of options and explain the desired outcome for each. Since the
--fill*options can affect both--titleand--body, I'm going to investigate them separately.Note
--fill*means any of--fill,--fill-first, or--fill-verboseoptions. These options are mutually exclusive.Determining PR title
Here's the order of precedence of options that can be used to specify a PR's title. Lower numbers (higher in the list) take precedence over the higher numbers:
--title: PR title input box must be pre-filled with "foo".--fill*:PR title input box must be pre-filled based on commit history.Determining PR body
--body-file <FILE>: PR body input box must be prefilled with the content of the given<FILE>.--body foo: PR body input box must be prefilled with "foo".--fill*: PR body input box must be prefilled based on commit history.--template <FILE>: PR body input box must be prefilled with the content of the given<FILE>.Note
The
--templateand--body(or--body-file) options are mutually exclusive.Note
--editorand--recoveroptions are not applicable in--webmode.