04-02-2016, 04:48 PM -
Hello again,
I have had way too much difficulty trying to get pull requests approved due to the requirement of rebasing/squashing/removing commits, so I'd like this thread to be a guide, or a workflow, for what to do when you submit a pull request to the RPCS3 repo.
I will confess that my first mistake was to not creating a feature branch to develop in. This would have allowed me to use my master branch for only keeping up-to-date with the upstream master branch, and my feature branch to test the changes in Visual Studio, Travis CI, and Appveyor.
However, since we're in the "it is what it is" boat, I want to make sure that I never have to go through this trouble again, so here are some questions that would benefit anyone making a PR, not just myself.
1: My project builds successfully on my local machine, but Appveyor and Travis CI failed to build my Pull Request. What do I do to make them pass?
I know the answer to this one, which is to make sure that appveyor.yml and .travis.yml are configured to build whatever changes you have made. For example: you added a new submodule? Make sure they both initialize that submodule.
2: I've been asked to make some changes to my PR. Do I need to submit a new one?
No, provided these conditions are met. First, as long as your PR is still open (not closed or merged), it will automatically update with any new commits you push to your branch - that is, the branch you made the pull request from. Thus, if you commit and push your changes to that branch, which should always be your master branch, then it will get added to your existing PR.
3: While my PR was open, someone made new changes to the upstream branch, and I am no longer up-to-date. What do I do to fix it?
Well, the only thing I know NOT to do is merge the changes that were made upstream. Before your PR is finished, you will be asked to squash your commits down to a single commit, and if you do that while there are merge commits in your history, you will inherit the responsibility of resolving every single conflict that comes up in that merge, whether it had already been solved by the original author or not.
To update from upstream WITHOUT doing a merge, run this command:
This assumes that you have upstream defined in git remote. This will also play your commits on top of the updates you just fetched.
4: What does it mean to squash commits? How do I do it? What if something goes wrong?
Assume you have a dozen or so small (one-file) commits. You can squash them into one big commit, which makes it quicker for Github to find out which commits broke the build in the future. Squashing is best done on your feature branch, not the master branch, because only YOU have worked on your feature branch, while content from other authors may show up on your master branch. Squashing is much easier when you are the only author involved.
There are many tutorials for how to squash online. Here is a good example: https://git-scm.com/docs/git-rebase
Note: squashing is only one specific function of git rebase. Rebase allows you to do other things, some of which directly rewrites your git history. Be extremely careful when using it.
___
I figure a guide like this would help newcomers get better acquainted with how to add to the project (once they are ready of course). It would also help the top-brass among you, so you don't have to waste time trying to explain this to the noobs.
I also made this so I could get a solid answer on what to do when my PR is out-of-date and I want to avoid merges (no offense Tambre).[/b]
I have had way too much difficulty trying to get pull requests approved due to the requirement of rebasing/squashing/removing commits, so I'd like this thread to be a guide, or a workflow, for what to do when you submit a pull request to the RPCS3 repo.
I will confess that my first mistake was to not creating a feature branch to develop in. This would have allowed me to use my master branch for only keeping up-to-date with the upstream master branch, and my feature branch to test the changes in Visual Studio, Travis CI, and Appveyor.
However, since we're in the "it is what it is" boat, I want to make sure that I never have to go through this trouble again, so here are some questions that would benefit anyone making a PR, not just myself.
1: My project builds successfully on my local machine, but Appveyor and Travis CI failed to build my Pull Request. What do I do to make them pass?
I know the answer to this one, which is to make sure that appveyor.yml and .travis.yml are configured to build whatever changes you have made. For example: you added a new submodule? Make sure they both initialize that submodule.
2: I've been asked to make some changes to my PR. Do I need to submit a new one?
No, provided these conditions are met. First, as long as your PR is still open (not closed or merged), it will automatically update with any new commits you push to your branch - that is, the branch you made the pull request from. Thus, if you commit and push your changes to that branch, which should always be your master branch, then it will get added to your existing PR.
3: While my PR was open, someone made new changes to the upstream branch, and I am no longer up-to-date. What do I do to fix it?
Well, the only thing I know NOT to do is merge the changes that were made upstream. Before your PR is finished, you will be asked to squash your commits down to a single commit, and if you do that while there are merge commits in your history, you will inherit the responsibility of resolving every single conflict that comes up in that merge, whether it had already been solved by the original author or not.
To update from upstream WITHOUT doing a merge, run this command:
Code:
git pull --rebase upstream masterThis assumes that you have upstream defined in git remote. This will also play your commits on top of the updates you just fetched.
4: What does it mean to squash commits? How do I do it? What if something goes wrong?
Assume you have a dozen or so small (one-file) commits. You can squash them into one big commit, which makes it quicker for Github to find out which commits broke the build in the future. Squashing is best done on your feature branch, not the master branch, because only YOU have worked on your feature branch, while content from other authors may show up on your master branch. Squashing is much easier when you are the only author involved.
There are many tutorials for how to squash online. Here is a good example: https://git-scm.com/docs/git-rebase
Note: squashing is only one specific function of git rebase. Rebase allows you to do other things, some of which directly rewrites your git history. Be extremely careful when using it.
___
I figure a guide like this would help newcomers get better acquainted with how to add to the project (once they are ready of course). It would also help the top-brass among you, so you don't have to waste time trying to explain this to the noobs.
I also made this so I could get a solid answer on what to do when my PR is out-of-date and I want to avoid merges (no offense Tambre).[/b]