[OT] How to make a second github PR

[syphilis]

Hi,

I've already got an open perl5 pull request that I'm not ready to close just yet.
Now I want to open a second perl5 pull request on a separate issue, involving different files - namely win32/makefile.mk and win32/GNUmakefile.

I've done some googling, and found that one way to do that would be to create a new branch and make the changes to the makefiles in it.
But I don't think that will work because the changes I've made in my current pull request were made in my fork's master branch - whereas they would have to have been made in a different branch, if I was ever going to make a second pull request without closing the first.
So, I'm thinking I might have snookered myself through lack of foresight.

The only solution that I can think of is to use a second github account with a second fork, in order to make this second pull request.
That's not something I really want to do. Is there another way ?

Cheers,
Rob

[Corion]

With git, you can rewind time and find a different point to branch off your second branch.

I imagine you have some structure like this:

   sysiphus/master   perl/blead
   |                 |
   ... patches       ... other patches
   |                 |
   |                 /
   +----------------/    <- here is where you branched off your change
+s, for example SHA 12abcd
   |

The easiest way is to then check out the point where you diverged from blead</>, create a new branch and apply your changes to <c>win32/makefile.mk there:

git checkout 12abcd
# check that we can build at this stage, make sure that you have all y
+our changes out of tree, just in case:
git clean -dfX && cd win32 && gmake test
# Create the new branch here, and check it out
git branch makefile-update
git checkout makefile-update

... apply your changes

# check that tests still pass
git clean -dfX && cd win32 && gmake test


git commit -m "voila"
git push github

[jo37]

I don't see a problem with a second pull request that originates from a different branch. The question is if these changes interfere in any way. This could result in a conflict depending on which request is processed first.

The master branch in Git is technically nothing special. It's special purpose is just a convention.

I'd go along something like this:

git checkout master
git branch feature_x
git reset --hard upstream/master
git pull upstream master
git checkout feature_x
git rebase master
# edit feature x
git add .
git commit
git push origin feature_x
# create pull request

EDIT: changed personal alias "co" to "checkout"

[salva]

You can create a new branch from the upstream master and then cherry-pick on top of it the changes you want to include in the pull-request.

[perlfan]

This ^^

$ git log # get SHA-second-commit of your second commit
$ git checkout master # whatever upstream "latest" is
$ git checkout -b second-pr
$ git cherry-pick <SHA-second-commit>
$ git push origin second-pr
# now get URL git prints to STDOUT and go to your uRL, make 2nd PR

To remove that commit from your first branch, git rebase -i HEAD^^^, then delete the line of the second commit you just cherry picket, save and exit $EDITOR.