Creating Proper Pull Requests

It's completely fine to just submit a small pull request without first making an issue, but if it's a big change that will require a lot of planning and reviewing, it's best you start with writing an issue first.

The steps given below are for the main Redox project repository - submodules and other projects may vary, though most of the approach is the same.

If you marked your MR as ready don't add new commits, because it will trouble the Jeremy's review, making him lost time by reading the text again

If you need to add new commits mark the MR as draft again

Using Git in terminal

  1. In an appropriate directory, e.g. ~/tryredox, clone the Redox repository to your computer using one of the following commands:

  • HTTPS:

    git clone https://gitlab.redox-os.org/redox-os/redox.git --origin upstream --recursive

  • SSH:

    git clone git@gitlab.redox-os.org:redox-os/redox.git --origin upstream --recursive

  • Use HTTPS if you don't know which one to use. (Recommended: learn about SSH if you don't want to have to login every time you push/pull!)

  • If you used bootstrap.sh (see Building Redox), the git clone was done for you and you can skip this step.

  1. Change to the newly created redox directory and rebase to ensure you're using the latest changes:

    cd redox

    git rebase upstream master

  2. You should have a fork of the repository on GitLab and a local copy on your computer. The local copy should have two remotes; upstream and origin, upstream should be set to the main repository and origin should be your fork. Log into Redox Gitlab and fork the Repository - look for the button in the upper right.

  3. Add your fork to your list of git remotes with

  • HTTPS:

    git remote add origin https://gitlab.redox-os.org/MY_USERNAME/redox.git

  • SSH:

    git remote add origin git@gitlab.redox-os.org:MY_USERNAME/redox.git

  • Note: If you made an error in your git remote command, use git remote remove origin and try again.

  1. Alternatively, if you already have a fork and copy of the repo, you can simply check to make sure you're up-to-date. Fetch the upstream, rebase with local commits, and update the submodules:

    git fetch upstream master

    git rebase upstream/master

    git submodule update --recursive --init

    Usually, when syncing your local copy with the master branch, you will want to rebase instead of merge. This is because it will create duplicate commits that don't actually do anything when merged into the master branch.

  2. Before you start to make changes, you will want to create a separate branch, and keep the master branch of your fork identical to the main repository, so that you can compare your changes with the main branch and test out a more stable build if you need to. Create a separate branch:

    git checkout -b MY_BRANCH

  3. Make your changes and test them.

  4. Commit:

    git add . --all

    git commit -m "COMMIT MESSAGE"

    Commit messages should describe their changes in present-tense, e.g. "Add stuff to file.ext" instead of "added stuff to file.ext". Try to remove duplicate/merge commits from PRs as these clutter up history, and may make it hard to read.

  5. Optionally run rustfmt on the files you changed and commit again if it did anything (check with git diff first).

  6. Test your changes with make qemu or make virtualbox.

  7. Pull from upstream:

    git fetch upstream

    git rebase upstream/master
  • Note: try not to use git pull, it is equivalent to doing git fetch upstream; git merge master upstream/master.

  1. Repeat step 10 to make sure the rebase still builds and starts.

  2. Push your changes to your fork:

    git push origin MY_BRANCH

  3. On Redox GitLab, create a Merge Request, following the template. Describe your changes. Submit!

  4. If your merge requests is ready, send the link on Redox Merge Requests room.

Using GitLab web interface

  1. Open the repository that you want and click in "Web IDE".
  2. Make your changes on repository files and click on "Source Control" button on the left side.
  3. Name your commits and apply them to specific branches (each new branch will be based on the current master branch, that way you don't need to create forks and update them, just send the proper commits to the proper branches, it's recommended that each new branch is a different change, more easy to review and merge).
  4. After the new branch creation a pop-up window will appear suggesting to create a MR, if you are ready, click on the "Create MR" button.
  5. If you want to make more changes, finish them, return to the repository page and click on the "Branches" link.
  6. Each branch will have a "Create merge request" button, click on the branches that you want to merge.
  7. Name your MR and create (you can squash your commits after merge to not flood the upstream with commits)
  8. If your merge request is ready, send the link on Redox Merge Requests room.
  • Remember that if you use forks on GitLab web interface you will need to update your forks manually in web interface (delete the fork/create a new fork if the upstream repository push commits from other contributors, if you don't do this, there's a chance that your merged commits will come in the next MR).