One of the common things we do during Linux kernel development is move a series of patches from one kernel version to a similar version (say Linux 4.1 to 4.1.12). This is required as new stable versions of particular kernel version are released. One approach is to merge, but then your changes are mixed in with upstream commits and are more difficult to manage. Git rebase offers a convenient way to move a set of patches. In the following example we have a series of changes we made (or patches we applied) on top of the 4.1 kernel.
Now we want to move the same patchset to the 4.1.12 stable kernel. To do this, we can use the following commands:
- git checkout -b 4.1.12-armv7-x0-dugen2 4.1-armv7-x0-dugen2 (create a new branch that will be rebased)
- git rebase –onto v4.1.12 v4.1 4.1.12-armv7-x0-dugen2
A few details on the git rebase arguments:
- –onto v4.1.12 (this tells git what version we want to move our changes to)
- v4.1 (upstream — tells git where our patchset starts)
- 4.1.12-armv7-x0-dugen2 (branch — is the branch to do the operation on)
After the rebase, our patchset looks very similar, only on top of the 4.1.12 kernel version.
It this example (which included many more patches than shown above), I only encountered one conflict which was easy to resolve. This process can also be used to move a patchset to a new kernel version (say 4.2, or 4.3), but you would obviously expect more conflicts.