Hey Geertjan, for your situation you can do some git magic. The basic principle is, that you need to know, that branches and tags are just pointers to ObjectIDs. So we will now do some renaming.
I'll also assume, that you have two remotes configured upstream: that points to the apache repository github: Your personal repository on github If you have other names, adapt! Your PR will not be recoverable (at least it might get ugly), but your commit will survive. I suggest to close this now. Start point: Your master branch diverged from upstream master after the commit "[NETBEANS-54] Module Review spi.java.hints" and you did two commits. I pulled your master branch and ran: git log --pretty=oneline -n 3 This gives you a short list of the committs and their ids. It should look like this: matthias@athena:~/src/incubator-netbeans$ git log --pretty=oneline -n 3 eb3c624635ac941a5ee9f4f905cf364a10061621 [NETBEANS-54] Module Review api.templates a1a47ca5f8d3a0991b1969617116c9de6f6f0001 [NETBEANS-54] Module Review api.visual cc42f40263c42b1e5fc6dabb1b934229cf26ace5 [NETBEANS-54] Module Review spi.java.hints matthias@athena:~/src/incubator-netbeans$ No first thing: move your work to a different branch: git checkout master # Make sure you are in your master branch git branch -m master review-pr # rename your current branch No we will reinstall a clean master branch: git branch master cc42f40263c42b1e5fc6dabb1b934229cf26ace5 Your master branch now points to the commit with the ID cc42f40263c42b1e5fc6dabb1b934229cf26ace5 and that is the last common point between you and upstream. Now we switch to master and bring it into sync with upstream: git checkout master # Switch from review-pr to master git branch --set-upstream-to upstream/master # Ensure your master track upstream master git pull # Get newest commits from upstream Now we cleanup your github git push -f github master # THIS IS YOUR PERSONAL REPOSITORY ON GITHUB DO NOT FORCE PUSH TO APACHE!!!!!! # Now you are ready to merge your branch as described: git pull # Make sure your master is still current git merge review-pr # Merge the working branch (we created it above) git push Now your work is in upstream and now you can use the normal "branch" and merge workflow. The difference to the hg (mercurial) workflow is, that the mercurial workflow had now review part and all work was directly pushed to master. Hope that helps Matthias Am Freitag, den 06.10.2017, 21:42 +0200 schrieb Geertjan Wielenga: > If you have done a fork instead of a branch, how would this step > above be > done: > > git merge <branch_backing_your_PR> > > Thanks, > > Gj > > On Fri, Oct 6, 2017 at 8:11 PM, Matthias Bläsing <mblaes...@doppel-helix.eu> > wrote: > Am Freitag, den 06.10.2017, 19:44 +0200 schrieb Geertjan Wielenga: > > Another question -- once we have reviewed a PR, and there's consensus on > > it, how do we do the merge? > > if the PR that should be merged was your own, you can do this: > > * git checkout master > * git pull (assuming you configured master to track upstream master) > * git merge <branch_backing_your_PR> > * git push upstream (assuming the apache repository is configure as > upstream) > > >
