RPCS3 Forums

Full Version: How to handle Pull Requests
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2

markus

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:

Code:
git pull --rebase upstream master

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]

tambre

Edited the 3rd point to note what you should do usually. (When you don't already have merge commits)

markus

Do you have an explicit command for doing that?

tambre

Assuming that upstream is the upstream, then you can simply do:
git rebase upstream/master

And if you have some uncommitted local changes, then:
git rebase upstream/master --autostash

markus

It says current master branch is up-to-date.

tambre

Then it probably is right. Though you'll have to also fetch the changes with git fetch upstream from the upstream.

markus

Unfortunately, my PR is still non-mergeable. See attached.

I see a bunch of updates on RPCS3/master that I don't have on my master. I would normally get these updates via merge, but since that is off the table due to rebasing, how do I get these updates?

tambre

You rebase to it. Assuming that you don't have any merge commits on your branch, otherwise you're kinda out of luck.

vlj

Is there an official rpcs3 wiki? I think having a small git guide on a wiki may be helpful.
Of course there's ton of git tutorial on the internet but I think people without previous source control experience may find them daunting at first.

tambre

(04-07-2016, 12:35 AM)vlj Wrote: [ -> ]Is there an official rpcs3 wiki? I think having a small git guide on a wiki may be helpful.
Of course there's ton of git tutorial on the internet but I think people without previous source control experience may find them daunting at first.

https://github.com/RPCS3/rpcs3/wiki
Pages: 1 2