Background
Upstreaming patches from a vendor kernel is a constant process of trying to get on board a train, falling behind, and hopping back on again.
Typically, a vendor kernel is based on an older version of the kernel. As a result, one has to forward port a series of patches against the latest kernel mainline. This is seldom a pain free affair, since the patches may not apply without manual edits. For example, the kernel interfaces may have changed, patches merged into mainline could have conflicting changes, and so on. On top of all of this, you have the reality that this task will need to be performed a number of times while you track mainline.
Basics
I usually perform cherry-picking of each patch on top of the mainline branch from the vendor branch, which is usually based on some old stable point release. Let’s assume that there are tags pointing to the vendor and stable commits, this reports the number of patches on top of that stable release.
panto@dev:~/linux (master)$ git describe stable
v4.1.15
panto@dev:~/linux (master)$ git describe vendor
v4.1.15-926-gea8c225
In this case, the patches are against stable v4.1.15 and there are 926 patches
on top of it; the format of the describe label is <tag>-<#-of-patches>-g<commit>
Workflow
First we get our needed information on the master branch.
panto@dev:~/linux (master)$ git describe master
v4.8-rc8-13-g53061af
Our master is today’s mainline kernel (v4.8-rc8) with just 13 patches on top of it. The problem with cherry-picking and manual editing is that when you edit the patch the commit id changes since the contents of the patch changes. We need a way to have a list of patches to cherry-pick, iteratively apply them, and manually fix any problems.
panto@dev:~/linux (master)$ git checkout --track -b work master
Checking out files: 100% (33262/33262), done.
Branch work set up to track local branch master.
Switched to a new branch 'work'
panto@dev:~/linux (work)$ git log --reverse --oneline stable..vendor >patchlist.txt
We create file with a list of the commits we want to apply on the work branch.
panto@dev:~/linux (work)$ cat patchlist.txt | head -n 2
ff24250 ppc: Make number of GPIO pins configurable
e4d443c pci/pciehp: Allow polling/irq mode to be decided on a per-port basis
This is the standard oneline format of git log (in reverse since we want the list to be in chronological order). If we were to do this manually, we’d have to do it like this:
panto@dev:~/linux (work)$ git cherry-pick ff24250
If the cherry-pick is successful, we can proceed with the next one and so on. Otherwise, we have to manually fix it and issue git cherry-pick –continue Why not automate this by picking out the commit from the list and work iteratively? We can’t simply use commit IDs because the commit ID changes after every edit. The following cherry-pick-list.sh script does the heavy lifting of picking out the commits for us. Given the patchlist file, it will git cherry-pick each commit in the list. However, it will skip the already applied commits which match the description. It does not consider commit IDs since those might have changed.
#!/bin/bash
# get top
top=`git log --oneline HEAD^..HEAD | head -n1`
ctop=`echo ${top} | cut -d' ' -f1`
dtop=`echo ${top} | cut -d' ' -f2-`
l="$ctop $dtop"
if [ "$l" != "$top" ] ; then
echo "Reconstructed top failure"
echo $top
echo $l
exit 5
fi
# get list of commits and descriptions
old_IFS=${IFS}
IFS=$'n'
j=0
for i in `grep -v '^#' $1`; do
c[${j}]=`echo ${i} | cut -d' ' -f1`
d[${j}]=`echo ${i} | cut -d' ' -f2-`
l="${c[${j}]} ${d[${j}]}"
if [ $l != $i ] ; then
echo "Reconstructed changeset failure $i"
exit 5
fi
((j++))
done
last=$((j - 1))
IFS=${old_IFS}
# skip over patches that are applied (checking description only)
match=0
for i in `seq 0 $last`; do
ct=${c[${i}]}
dt=${d[${i}]}
if [ "${dt}" == "${dtop}" ]; then
echo "Match found at $i: $dt"
match=$(($i + 1))
break;
fi
# echo "$i: $ct $dt"
done
for i in `seq $match $last`; do
ct=${c[${i}]}
dt=${d[${i}]}
echo "cherry-picking: $i: $ct $dt"
git cherry-pick $ct
if [ $? -ne 0 ] ; then
exit 5;
fi
done
It makes sense to work on a simplified example using the kernel’s README file.
panto@dev:~/linux (work)$ git checkout --track -b foo master
Switched to branch 'foo'
Your branch is up-to-date with 'master'.
Edit the README file resulting to the following patch:
panto@dev:~/linux (foo)$ git diff
diff --git a/README b/README
index a24ec89..947fe6c 100644
--- a/README
+++ b/README
@@ -6,6 +6,8 @@ kernel, and what to do if something goes wrong.
WHAT IS LINUX?
+ foo
+
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
Commit the change:
panto@dev:~/linux (foo)$ git commit -m 'foo description'
[foo 4b5f122b] foo description
1 file changed, 2 insertions(+)
List the patches on top of master in sequence:
panto@dev:~/linux (foo)$ git log --oneline --reverse master..foo
4b5f122b foo description
Let’s create a new bar branch:
panto@dev:~/linux (foo)$ git checkout --track -b bar master
Switched to branch 'bar'
Your branch is up-to-date with 'master'.
Edit the README file resulting to the following patch:
panto@dev:~/linux (bar)$ git diff
diff --git a/README b/README
index a24ec89..4e7043c 100644
--- a/README
+++ b/README
@@ -6,6 +6,8 @@ kernel, and what to do if something goes wrong.
WHAT IS LINUX?
+ bar
+
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
Note that this conflicts with the foo patch, we will need to manually fix it later.
Commit the change:
panto@dev:~/linux (bar)$ git commit -m 'bar description'
[bar aba1679] bar description
1 file changed, 2 insertions(+)
Make another commit that is conflict free:
panto@dev:~/linux (bar)$ git diff
diff --git a/README b/README
index 2788bfc..fbdf488 100644
--- a/README
+++ b/README
@@ -412,3 +412,4 @@ IF SOMETHING GOES WRONG:
gdb'ing a non-running kernel currently fails because gdb (wrongly)
disregards the starting offset for which the kernel is compiled.
+ more bar
Switch back to the foo branch to apply the changes in the bar branch.
panto@dev:~/linux (bar)$ git checkout foo
Switched to branch 'foo'
Your branch is ahead of 'master' by 1 commit.
(use "git push" to publish your local commits)
Generate the patchlist file:
panto@dev:~/linux (foo)$ git log --oneline --reverse master..bar | tee patchlist.txt
22d7ac6 bar description
2be1bbb more bar description
Apply them using the script:
panto@dev:~/linux (foo)$ cherry-pick-list.sh patchlist.txt
cherry-picking: 0: 22d7ac6 bar description
error: could not apply 22d7ac6... bar description
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
Recorded preimage for 'README'
panto@dev:~/linux (foo)$ git diff
diff --cc README
index 947fe6c,4e7043c..0000000
--- a/README
+++ b/README
@@@ -6,7 -6,7 +6,11 @@@ kernel, and what to do if something goe
WHAT IS LINUX?
++<<<<<<< HEAD
+ foo
++=======
+ bar
++>>>>>>> 22d7ac6... bar description
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
Edit and fix it to look like this:
panto@dev:~/linux (foo)$ git diff
diff --cc README
index 947fe6c,4e7043c..0000000
--- a/README
+++ b/README
@@@ -6,7 -6,7 +6,8 @@@ kernel, and what to do if something goe
WHAT IS LINUX?
+ foo
+ bar
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
panto@dev:~/linux (foo)$ git add README
Edit the commit message (leaving the conflict or removing the Conflicts: tag)
panto@dev:~/linux (foo)$ git cherry-pick continue
Recorded resolution for 'README'.
[foo cc9dc34] bar description
1 file changed, 1 insertion(+)
Note the Recorded resolution line. Next time we will perform the same operation so we don’t have to repeat the manual fix. Run the script again to pick up the rest of the patchlist.
panto@dev:~/linux (foo)$ git cherry-pick continue
Match found at 0: bar description
cherry-picking: 1: 2be1bbb more bar description
[foo 63c1973] more bar description
1 file changed, 1 insertion(+)
Note the message Match found at 0:. The script picked up that the first commit has been applied (albeit manually edited) and continued with the rest, which apply without problems. List the patches on top of master on the foo branch. Note that the commit ids of the patch sequence have changed.
panto@dev:~/linux (foo)$ git log --oneline --reverse master..
4b5f122b foo description
cc9dc34 bar description
63c1973 more bar description
Now if we reset the foo branch back to the starting point:
panto@dev:~/linux (foo)$ git reset --hard HEAD^^
HEAD is now at 4b5f122b foo description
Try to apply the patchlist again to see what happens:
panto@dev:~/linux (foo)$ cherry-pick-list.sh patchlist.txt
cherry-picking: 0: 22d7ac6 bar description
error: could not apply 22d7ac6... bar description
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
Resolved 'README' using previous resolution.
Note the Resolved ‘README’ using previous resolution. This means that git determined that we are trying to perform the same edit and already made the change for us. Of course, it didn’t commit the change so that we have a chance to verify that it is correct.
panto@dev:~/linux (foo)$ diff --cc README
index 947fe6c,4e7043c..0000000
--- a/README
+++ b/README
@@@ -6,7 -6,7 +6,8 @@@ kernel, and what to do if something goe
WHAT IS LINUX?
+ foo
+ bar
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
Just add the changed file as earlier:
panto@dev:~/linux (foo)$ git add README
panto@hp800z:~/juniper/linux-medatom.git (foo)$ git cherry-pick --continue
[foo 2586dba] bar description
1 file changed, 1 insertion(+)
Use the script again and end up at the same result:
panto@dev:~/linux (foo)$ ./cherry-pick-list.sh patchlist.txt
Match found at 0: bar description
cherry-picking: 1: 2be1bbb more bar description
[foo 6641dd4] more bar description
1 file changed, 1 insertion(+)
I’m not a regular git guru but I found out that this small script ended up saving me a large amount of repetitive work. I hope someone else will find this useful.
