Hello Toradex community,
My project requires me to make modifications to the Toradex linux kernel. My workflow is that I develop the kernel separately and when I’m happy with the modifications I push them to my enterprise git repo and then have yocto pull and build the kernel based on a specified commit from that repo. This workflow works fine.
For context I’m calling the git.toradex.com remote “toradex” and my enterprise server is “origin”.
Currently my modifications are against toradex_imx_3.14.28_1.0.0_ga and I would like to upgrade to 3.14.52 while preserving those modifications. This is what I do:
# Check out the local 3.14.28 based branch with my modifications
git checkout my_toradex_imx_3.14.28_1.0.0_ga
# Create a new branch intended for 3.14.52 merge
git checkout -b my_toradex_imx_3.14.52_1.1.0_ga
# Merge with upgraded Toradex branch
git fetch toradex && git merge toradex/toradex_imx_3.14.52_1.1.0_ga
However this is causing a large amount of conflicts:
$ git merge toradex/toradex_imx_3.14.52_1.1.0_ga
Auto-merging sound/soc/soc-core.c
Auto-merging sound/soc/fsl/imx-wm8962.c
CONFLICT (content): Merge conflict in sound/soc/fsl/imx-wm8962.c
Auto-merging sound/soc/fsl/imx-mqs.c
CONFLICT (add/add): Merge conflict in sound/soc/fsl/imx-mqs.c
Auto-merging sound/soc/fsl/imx-cs42888.c
...
I would expect there to be some conflicts related to my own modifications but these conflicts are mostly with files I haven’t touched.
This leads me to the conclusion that my upgrade workflow is flawed, granted I’m unexperienced with linux development.
Can you please suggest a less conflict prone way for me to migrate between Toradex kernel versions?
Thank you,
Gardar
With vanilla mainline your strategy may work. However with vendor branches like ours based on another vendor branch from Freescale/NXP there likely will be lots of incompatible changes. The underlying issue is that the new 3.14.52 branch is not just a simple successor of the old 3.14.28 branch but rather a somewhat evolutionary new development containing lots of reworked or even new commits. So in most cases just cherry picking the handful of your changes if still applicable will probably be the simplest approach.
Hi,
Maybe I can help you. I don’t know if this is the right way but it works for me.
The way I do it is using git patches.
If you have your local branch my_toradex_imx_3.14.28_1.0.0_ga which helds your modifications against toradex_imx_3.14.28_1.0.0_ga branch then you simply do (while in my_toradex_imx_3.14.28_1.0.0_ga branch):
git format-patch toradex_imx_3.14.28_1.0.0_ga --stdout > my_patch.patch
That way all your modifications against toradex_imx_3.14.28_1.0.0_ga branch are stored in my_patch.patch file.
Next step is to checkout new branch:
git checkout -b toradex_imx_3.14.52_1.1.0_ga
Create new patched branch:.
git checkout -b toradex_imx_3.14.52_1.1.0_ga_patched
and then apply created patch over it. That way only your changes will be applied over new branch. You still can get error like patch failed on some files. You can merge those files manualy.
While in toradex_imx_3.14.52_1.1.0_ga_patched branch you can check your modifications with
git diff toradex_imx_3.14.52_1.1.0_ga
Sandi
This is basically just what git cherry-pick which I suggested to use will do in one single step.
Didn’t know about that command. I’ll use it from now on. Thank you.
Hi all,
marcel.tx and mlinar gave very helpful answers, below is a summary of what worked for me:
# check out the old branch with modifications
git checkout my_toradex_imx_3.14.28_1.0.0_ga-next
# create some search query to filter out local commits
git log --pretty=oneline --author=".*mycompany.com.*"|tac
# check out the new Toradex branch
git checkout toradex/toradex_imx_3.14.52_1.1.0_ga
# create a local branch based on the new Toradex branch
git checkout -b my_toradex_imx_3.14.52_1.1.0_ga
# for each commit listed in git log above
git cherry-pick xxxxxxxxx
Thanks for the help!
If your history on-top of the old branch is linear, you can simple use rebase:
git checkout mytree
git rebase --onto toradex/toradex_imx_3.14.52_1.1.0_ga
