Background

The Linux kernel goes through several "release candidate" or "-rc" versions for 6-8 weeks until it is stablized. After the stable kernel is released, the "merge window" opens where maintainers will send pull requests to Linus for him to pick up new patches. Once the first release candidate is published (-rc1), only bug fixes can go into the kernel.

In order to prepare for the merge window far in advance, kernel subsystem maintainers often keep a "-next" tree. This stores all the patches that will be sent to Linus during the next merge window. Maintainers' "-next" trees are pushed into the "linux-next" tree, where maintainers make sure their subsystems don't add conflicting code changes. The "linux-next" tree is rebased all the time, and is generally not an easy tree to work with.

Instead, we recommend creating patches directly on top of the subsystem maintainer's -next trees. In this example, we'll work through adding the staging-next tree as a remote, and rebasing any patches on top of the tree.

Initial rebase

1. Add the staging tree as a git remote:

git remote add staging git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git

2. Fetch the latest version of the staging tree:

git fetch staging

3. Now, if you run git remote -a, you will see lines that indicate you have a remote named staging, and it has branches called "master", "staging-linus" (fixes for the current -rc), and "staging-next" (patches queued for the next kernel version):

$ git branch -a | grep staging
  remotes/staging/master
  remotes/staging/staging-linus
  remotes/staging/staging-next

4. Next, checkout a new branch with your current work on it:

git checkout -b staging-fixes-rebase

5. Finally, rebase your fixes against the staging next branch:

git rebase staging/staging-next

You may need to clean up any code conflicts, so that your patches apply cleanly against the staging tree. This page might help explain how to do that (although in your case, you have a merge conflict due to a rebase, not from a merge commit).

When do I want to rebase again?

Occasionally, you may want to update your git repository against the latest -next version. Usually you want to make sure you rebase your tree before you start working on a new patch, in order to make sure your change isn't already in the -next branch. However, that can be problematic if you have patches under review in your current branch. If your new patches depend on your old patches (meaning they apply to the same driver files), you shouldn't rebase until the previous patches have been applied (when you get an automated email from Greg saying it was applied).

If you want to work on a different driver, you should checkout a new git branch, based on the latest -next tree:

git fetch staging
git checkout -b new-branch staging/staging-next

Then you can make changes and send off your patches. It's a good idea to have separate branches for each driver you're working on, in order to make sure it's easy to rebase and re-work your patches.