Repository navigation
gh pr push #2189
Description
Activity
hub pushdoes nothing else but executegit push, since hub is a proxy forgit.You will find that this works if the maintainer has given you access to their PR:
gh pr checkout 123 # (do some commits…) git pushReacted by Brent Shaffer, Lam Tang, Ian Storm Taylor, Janosh Riebesell, Jordan Harband, Frank Falor, Zachary Snow, Bryan Braun, Bernhard Kaindl, Max Howell and 9 moreReacted by Jason R. Coombs, Alex Goodman, Evan Jones, Ben Hutton, Grzegorz Krukowski, edgar-db, Patrick Heneise, Michael Martinez, cospectrum, Lukas Klingsbo and 6 moreReacted by Damien AlexandreThanks @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.
Reacted by Mislav Marohnić, Ophir LOJKINE, Vladimir Jimenez, Grzegorz Krukowski, edgar-db, Jason Axelson, Baptiste Mathus, pchiang-godaddy, Maks Rafalko, Sukka and 3 moreHi @mislav
I wanted to improve this PR: facebook/docusaurus#3613
I run
gh pr checkout 3613and did my local commits.Then I tried the
git pushbut 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 pushmay not be enough?
Not sure what is happening with the 403 error either.
ochedruis 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
ochedrushow up in the error message?
I can try again on another PR soon if you need another case
Reacted by Jason Axelson and Sukka@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.comFrom the
Remote: permission to {REPO} denied to ochedruerror 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"
Reacted by Ryan MulliganReacted by SukkaI'm having a very similar issue here with
ghand 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
ghthinks I am logged in but my push fails. Shouldn't being authenticated byghconfigure an access token for the repo automatically?@bsiegel Right now,
ghstill 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 checkoutset the upstream remote so that the commits go to the PR branch. Of course,git pushwill fail if the PR author hasn't allowed edits from maintainers, but that's expected behaviour.Reacted by Johan Ljunggren, Dirk Avery, Jason R. Coombs, y7o4ka, Domenic Denicola, Maël Valais, Wish, Colin Anderson, Rain Sallow (/u/ta11ow), Ivo Jimenez and 26 moreFYI 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.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)"Reacted by Naser Aleisa, Jacob and Maks Rafalko@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 pushand 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 checkoutsince many people are not going to read the docs
Reacted by Mislav Marohnić, Ivan, Brandon Kraft, Maël Valais, Joe Previte and Sukka- add a mention to https://cli.github.com/manual/gh_pr_checkout of how most people should be able to
16 remaining items
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
Reacted by Adrian HeskethThe
git push <remote>commands mentioned here do not work. The refspec portion must be specified because the local branch created bygh pr checkoutdoes 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
masterbranch in the fork.This definitely needs first-class support, not just an alias or other workaround, in order to hide the plumbing from users.
Reacted by Dennis Kieselhorst, Bernhard Kaindl, Jacob Scherber and Matthias Diester@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 -fwork on branches thatgh pr checkoutcreates, whether the pushRemote matches the branch name or not.Reacted by Heb, Scott Hansen, Tomáš Bedřich, Andrei, Bernhard Kaindl, Kyℓe Hensel and Maks RafalkoReacted by Bernhard KaindlIt 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
Reacted by M Sazzadul Hoque, Raphael and Chris Hayes@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).
Reacted by Jason Axelson, Nico Flaig, Dennis Kieselhorst, Bernhard Kaindl, Sridhar Ratnakumar, Jonathan Hefner and LoveSyIt 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 andgit pushwon't work.@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 -fwork on branches thatgh pr checkoutcreates, 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 agit rebaseto 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.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 :-)
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 pushJust 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: