Allow setting a default push target for pr create

In #1706 we've changed pr create so it no longer automatically pushes to a remote, but prompts instead. We made that change because, during beta, we weren't able to find a default that people would be generally satisfied with. Some people always want to push to their fork, some always want to push to the base repo even though they might have a fork, and some want to avoid auto-pushing altogether. Finally, for people working on work or otherwise private projects, it doesn't make sense to ask for a push target because there is usually only one, centralized target.

The new change adds an extra step to pr create that some people might find tedious and repetitive, especially when they already know up front that they always want to push to the same remote. We could either, or both

Allow explicitly setting a default push target. I imagine this setting should be per-repository instead of global;
After the user chooses a push target for the first time, we could remember it and automatically choose it the next time. Although, this could potentially be surprising and unwanted on subsequent pushes.

Thank you for a great addition to my daily workflow (with the cli), but I was confused after the latest update.

Glad to see you already have an issue for it and 👍 for it being per-repository!

A hybrid of the two: when choosing a push target for the first time, prompt whether to remember it for this repository (and also offer a command to undo or change that decision later).

For better issue search results and less duplicates: "Where should we push the ... branch?"

What about a cli flag instead of/in addition to the default? That way people can create aliases for the option(s) they want.

For instance I have the alias cw: pr create -w because I like my PRs to be created in a browser.
Similarly I could create a new alias (or modify this one) with the flag to chose the pushing option I want.

@patatepartie

What @patatepartie suggested is what I want from this. Really enjoyed the workflow of running gh pr create -f and BAM, I have a PR ready. It's a super slick workflow. If I had to add an extra consistent flag with no unique argument to get that workflow back, then 💯 for it!

@polothy

Yeah, I echo both @polothy & @jglick. The combination of

a flag like gh pr create --upstream/--fork would be great for non-interactive use
and for interactive use: the behavior of when choosing a push target for the first time, prompt whether to remember it for this repository (and also offer a command to undo or change that decision later)

would be awesome to see. I run gh pr create -f alot as well, and I'm looking forward to having that finish without interaction once this is implemented

I echo the sentiment above. I'm still running 0.12 because losing my gh prf alias/workflow is too high of a price for me.

Since git config already defines remote.pushDefault to specify which remote to push to by default, and also defines push.default to specify how to push when no refspec is given, it seems reasonable that pr create should support respecting these configuration entries if present, rather than introducing a new GitHub-CLI-specific mechanism to achieve the same result.

rather than introducing a new GitHub-CLI-specific mechanism to achieve the same result

I am not familiar with all the options available in Git here, but one way or another I would want to differentiate git push to an existing tracking branch such as origin/master (e.g. typo fix in README.md) from gh pr create (should always push to my fork).

IMHO explicit command line options are better than magic defaults, I would like to be able to use gh pr create in a non interactive way in Travis CI and with the prompt I cannot find a workaround now, happy to learn if any -- basically the equivalent of hub pull-request --no-edit -p

@mteodori

@mteodori My aim is to enable something like that! But until the next feature release that allows this, I would suggest the following approach for scripting/automation:

$ git push -u origin HEAD
$ gh pr create --fill

I really miss option to avoid this last confirmation. I do want to push always when I create a PR and I would love gh pr create --fill to be really one-click command. Maybe --push=repo or any settings, whatever, but I'm really annoyed by this extra confirmation =(

As mentioned in my issue (which I didn't see this duplicate before)
In the cli for gitlab they have the tooling to do this change

https://github.com/profclems/glab/blob/b9d2554f19351276922a8f83bbff11fc5d2e36b9/commands/mr/create/mr_create.go#L374

The solution they proposed is:

glab mr create --fill -y

And the first time it sets the default push target and pushed there each time

I hope that helps

is there a workaround to bypass interaction on

gh pr create --fill

@mteodori

@mteodori My aim is to enable something like that! But until the next feature release that allows this, I would suggest the following approach for scripting/automation:
$ git push -u origin HEAD
$ gh pr create --fill

 !  ~/r/c/Cataclysm   check-translations *$…  git push -u origin HEAD && gh pr create -w                                                                                                                10.1s  2023년 10월 03일 (화) 오후 10시 47분 00초branch 'check-translations' set up to track 'origin/check-translations'.
Everything up-to-date
Warning: 5 uncommitted changes
? Where should we push the 'check-translations' branch?  [Use arrows to move, type to filter]
> cataclysmbnteam/Cataclysm-BN
  scarf005/Cataclysm-BN
  Skip pushing the branch
  Cancel

this solution does not seem to work.

fix: set target push branch for gh pr create command

the solution implemented is a --head flag
so for example I can do my full automated process like this

# notice I just create the branch and I now I'm able to push to this new --head
    git checkout -b "BOT-Conversor-Migra-SQL-v${maxMajorVersion}.${newMinorVersion}"
    git commit -am "Update SQL-Scripts [$list_scripts_string]"
    git push origin "BOT-Conversor-Migra-SQL-v${maxMajorVersion}.${newMinorVersion}"

    gh pr create -a "Joao-Victor-EM" -b "Migrate to [${maxMajorVersion}.${newMinorVersion}]" -t "SQL Migration v${maxMajorVersion}.${newMinorVersion}" -B hmg --head "BOT-Conversor-Migra-SQL-v${maxMajorVersion}.${newMinorVersion}"

This seems to defeat the entire purpose of the --fill flag.

Weirdly I swear this was working for me last week, but now I am prompted every time. Extremely annoying UX.

The advice to git push -u origin HEAD doesn't have any effect nor does the advice to use a filter tree instead of a shallow clone.

pkg/cmd/pr/create: support --push-repo option

@arturhoo

Experience report:

For my main work repo I use a script to do pre-PR checks (run longer linter, etc) and then call gh pr create --fill. Many times I've come back to the terminal where I ran it and found the "which repo?" prompt waiting for me. I always want the first option.

I put together danp@093bf98 which adds --push-repo <remote name | user/repo>. That lets me use gh pr create --fill --push-repo origin and it works exactly how I want.

I think it ended up pretty similar to @arturhoo's attempt in #8146 but I didn't quite find that until after.

pkg/cmd/pr/create: support --push-repo option

Experience report:

it seems that the prompt will not appear if you have set a upstream correctly.

I ran git config --global push.autoSetupRemote true, so every when i push a branch, git will automatically set up the upstream for me.

after that when i run gh pr create --base main --fill --web, the prompt does not show up.

I hope it helps whoever stumble into this situation.

(but mind you, you might run into a situation like in #1718 (comment))

As a workaround following #1718 (comment) I am testing

aliases:
  prfork: '!git push -u fork HEAD && gh pr create "$@"'

(Note that gh help alias set is not very helpful regarding extra arguments combined with --shell mode.)

pkg/cmd/pr/create: support --push-repo option

Sadly that git push -u origin HEAD is very dangerous, I already pushed to main by mistake on a personal repository. If you ever make the mistake to run from main branch, you may be sorry. I am afraid that a good/safe solution would look far more complex. I am planning to do one but I will likely need a full weekend for that.

GitHub rulesets (or the older Branch Protection) are the solution for this.

Navigation Menu

Repository navigation

Allow setting a default push target for `pr create` #1718

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow setting a default push target for pr create #1718

Description

Activity

davidwessman commented on Sep 17, 2020

jglick commented on Sep 17, 2020

fdcds commented on Sep 23, 2020

patatepartie commented on Oct 1, 2020

polothy commented on Oct 1, 2020

AndrewSB commented on Oct 12, 2020

dato commented on Dec 3, 2020

jstangroome commented on Dec 16, 2020

jglick commented on Dec 16, 2020

mteodori commented on Dec 18, 2020

mislav commented on Dec 18, 2020

okainov commented on Apr 29, 2021

georgettica commented on Aug 13, 2021

11 remaining items

sibelius commented on Aug 5, 2023

scarf005 commented on Oct 3, 2023

Joao-Victor-EM commented on Jan 2, 2024

lmmx commented on Jan 29, 2024

danp commented on Mar 20, 2024

sevensinjai commented on May 10, 2024

jglick commented on May 10, 2024

ericis commented on Aug 22, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Allow setting a default push target for `pr create` #1718