gh pr push

Describe the feature or problem you’d like to solve

As a maintainer, I want to be able to push easily to the fork of a contributor (if he granted permission).
We need this to help unlock contributors if they are stuck on some difficult part.

Proposed solution

gh pr checkout 123

# do local commits to unlock the contributor

gh pr push

Just discovered Hub, and found out that it had a similar feature: https://jonathanchang.org/blog/pushing-to-a-pull-request-on-github/
I think it make sense to have this on the "official" cli too?

My current workaround is:

gh pr checkout 123

# do local commits to unlock the contributor

git push [email protected]:username/projectName.git

hub push does nothing else but execute git push, since hub is a proxy for git.

You will find that this works if the maintainer has given you access to their PR:

gh pr checkout 123
# (do some commits…)
git push

@mislav

Thanks @mislav , will try that.

Last time I tried that, afaik it pushed to upstream repo, not forked repo. I want to contribute to the fork, as the contributor should be able to continue working on his PR updated with my fixes.

Will double-check to see if your suggestion works.

@mislav

Hi @mislav

I wanted to improve this PR: facebook/docusaurus#3613

I run gh pr checkout 3613 and did my local commits.

Then I tried the git push but it didn't work. Only when I added remote repo URL did my commit end up showing in the PR

Only the 2nd command was able to push to the PR:

So it looks like git push may not be enough?

Not sure what is happening with the 403 error either. ochedru is a dev I worked with 2 years ago, on a totally different project 😅 he never contributed to Docusaurus in any way.

Recently upgraded GH cli and had to login again just before, not sure it's related...

Any idea what is happening here? and why ochedru show up in the error message?

I can try again on another PR soon if you need another case

@slorber

@slorber Do you prefer HTTPS or SSH protocol for git cloning/pushing? It looks like you prefer SSH, but gh defaults to HTTPS, as evident by it setting up a HTTPS push URL after gh pr checkout.

You can change the default with:

gh config set git_protocol ssh -h github.com

From the Remote: permission to {REPO} denied to ochedru error message, I suspect that the git credential helper for HTTPS repos had some credentials cached that belong to ochedru. See:

 $ git config credential.helper
osxkeychain

$ git credential-osxkeychain get <<<"host=github.com
protocol=https"

I'm having a very similar issue here with gh and HTTPS remotes.

$ gh pr checkout 123
From github.com:MyUser/myrepo
 * [new ref]         refs/pull/123/head -> branchname
Switched to branch 'branchname'

$ git push
Username for 'https://github.com': ^C

$ gh auth status
github.com
  ✓ Logged in to github.com as bsiegel (~/.config/gh/hosts.yml)
  ✓ Git operations for github.com configured to use https protocol.

I don't understand why gh thinks I am logged in but my push fails. Shouldn't being authenticated by gh configure an access token for the repo automatically?

@bsiegel

@bsiegel Right now, gh still doesn't set your Git credentials even after you log in. You will need to configure git manually.

However, we are working on a feature that will take care of this automatically for you: #1434

for the record I had a convo with the maintainers and they said that this functionality actually exists in the CLI, it was just totally undocumented bc it has edge cases that aren't nice (eg if you have branch name conflicts) . so I guess we wait for them to document it and or to implement the custom gh PR push logic accounting for edge case.

I just came across this issue. The problem is that when you do git push, git doesn't know where to push your commits to.

I think this can be solved very cleanly if gh pr checkout set the upstream remote so that the commits go to the PR branch. Of course, git push will fail if the PR author hasn't allowed edits from maintainers, but that's expected behaviour.

@mislav

FYI Ashley - this is what @mislav said:

FWIW, we do go to extra lengths to set up upstream configuration after gh pr checkout so that a plain git push will Just Work™ in a lot of cases. based on user feedback, this is not apparent to our users, since the pr checkout command doesn't tell you that it set it up, and we haven't documented it either.

however, when there are branch naming conflicts and the locally checked out branch is differently named than the "head" branch of a PR, git push without arguments will not work anymore.
I agree that a dedicated command that would handle all of those cases transparently would be a good idea.

@AshleyYakeley

Precisely.

@AshleyYakeley You can check the configuration that GitHub CLI sets:

$ gh pr checkout 123
$ git config -l | grep -F "branch.$(git branch --show-current)"

@mislav

@mislav 2 suggestions that might be easy to implement:

add a mention to https://cli.github.com/manual/gh_pr_checkout of how most people should be able to git push and have it "just work" (i personally havent even tried it since we chatted.. old habits die hard)
perhaps add a console message log the first or N or every time someone does a new gh pr checkout since many people are not going to read the docs

Has there been any update on this? I just spent an hour trying to make a silly change to an existing PR, frankly this isn't worth my time as an occasional contributor. People like me are actively discouraged from contributing.

At the very least can the github web interface be changed so that gh checkout is removed as an "easy" way of checking out a PR for editing, because obviously it is not.

If that cannot be done, can a clear help message be made as to what the recommended procedure is? I think I accidentally did the right thing somehow but I wouldn't be able to reproduce it next time.

good

The git push <remote> commands mentioned here do not work. The refspec portion must be specified because the local branch created by gh pr checkout does not match the name of the upstream branch. No remote tracking branch was set for me, either.

The command I used was:

git push [email protected]:user/fork.git +@:master

The PR in question happened to be from the master branch in the fork.

This definitely needs first-class support, not just an alias or other workaround, in order to hide the plumbing from users.

@rcdailey

@rcdailey thanks, that helped me craft this command:

git push $(git config --get branch.$(git symbolic-ref HEAD --short).pushRemote) +@:$(git config --get branch.$(git symbolic-ref HEAD --short).merge | awk -F / '{print $NF}')

which I then aliased in my gitconfig:

[alias]
  pushRemote = !git push $(git config --get branch.$(git symbolic-ref HEAD --short).pushRemote) +@:$(git config --get branch.$(git symbolic-ref HEAD --short).merge | awk -F / '{print $NF}')

which makes git pushRemote -f work on branches that gh pr checkout creates, whether the pushRemote matches the branch name or not.

It looks like pushing to remote/fork branch now just works using git

Checkout branch of PR

gh pr checkout <pr_number>

Then simply push

git push

Pulling works as well

git pull

@nflaig

@nflaig that doesn’t work if the local and remote branch have different names - which happens if you already have a branch with that name (like master or main).

It looks like pushing to remote/fork branch now just works using git

Checkout branch of PR
gh pr checkout <pr_number>
Then simply push
git push
Pulling works as well
git pull

This is great if you're checking out a PR that you haven't previously worked on -- if you first check out a branch, and then use gh pr create, your local branch is never associated with the upstream branch and git push won't work.

@rcdailey

@rcdailey thanks, that helped me craft this command:
git push $(git config --get branch.$(git symbolic-ref HEAD --short).pushRemote) +@:$(git config --get branch.$(git symbolic-ref HEAD --short).merge | awk -F / '{print $NF}')
which I then aliased in my gitconfig:
[alias]
  pushRemote = !git push $(git config --get branch.$(git symbolic-ref HEAD --short).pushRemote) +@:$(git config --get branch.$(git symbolic-ref HEAD --short).merge | awk -F / '{print $NF}')
which makes git pushRemote -f work on branches that gh pr checkout creates, whether the pushRemote matches the branch name or not.

Be careful with your alias. The + in the refspec indicates that the source should overwrite the destination; effectively a force push. I did things this way in my scenario because I did a git rebase to clean up the PR commits.

Some users may not want force push semantics. In that case, a secondary version of that alias without the + in the refspec argument is desirable.

@rcdailey

@rcdailey yes, that's intentional, i always am rebasing and thus force pushing when i'm pushing to a PR. good callout tho.

Then you should also make sure to always disable “maintainers can push", or they push something, you don't recognize and due to your alias simply overwrite

I’m not sure how those aliases could ever result in overwriting something.

You do a force-push, so they overwrite anything. For pushing a rebase this is necessary, but if there were changes by the maintainer you did not fetch, you also overwrite those

oh, sure. but the push and the PR will show the hash i overwrote so i can look at it :-)

Navigation Menu

Repository navigation

gh pr push #2189

Describe the feature or problem you’d like to solve

Proposed solution

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

gh pr push #2189

Description

Describe the feature or problem you’d like to solve

Proposed solution

Activity

mislav commented on Oct 14, 2020

slorber commented on Oct 14, 2020

slorber commented on Oct 21, 2020

mislav commented on Oct 21, 2020

bsiegel commented on Oct 22, 2020

mislav commented on Dec 9, 2020

swyxio commented on Dec 9, 2020

AshleyYakeley commented on Jan 6, 2021

swyxio commented on Jan 6, 2021

mislav commented on Jan 6, 2021

swyxio commented on Jan 6, 2021

16 remaining items

mthibaut commented on May 10, 2023

cubxxw commented on May 11, 2023

rcdailey commented on Jun 24, 2023

ljharb commented on Jun 29, 2023

nflaig commented on Jul 19, 2023

ljharb commented on Jul 19, 2023

taliastocks commented on Feb 1, 2024

rcdailey commented on Feb 1, 2024

ljharb commented on Feb 2, 2024

Vampire commented on Feb 2, 2024

ljharb commented on Feb 2, 2024

Vampire commented on Feb 2, 2024

ljharb commented on Feb 2, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions