I was pleased to find out that the new ArduPlane version 4.1.0 was finally released. I have a local github repo with some changes to ArduPlane 4.0.9 that i would now like to integrate into 4.1.0 now. When i tried to merge i found out that the point in time where 4.1.0 and 4.0.9 were related to each other is a long while back. And there are a lot of commits on 4.0.9 that are not in 4.1.0. Now normally i would think that there would be some kind of ArduPlane release branch, where the latest released version gets merged in. That would automatically resolve any headache in migrating custom changes onto the latest version. I quickly tried merging 4.1.0 into 4.0.9 this morning and found that there were lots of conflicts and by just accepting the 4.1.0 side the result was not compile-able. What is the right way to go from now on?
hello,
You should start from 4.1 and only merge your patch. Everything in the 4.0.x series as already been merged into the master branch long time ago and thus also belong to 4.1. Some patchs may be slighly differents because of the librairies API changes between the two versions.
Ideally you should submit your changes to be considered for inclusion in ArduPilot master, which means they make it into future releases. Some changes are not suitable for that however. I don’t know if your changes would be accepted without seeing them.
Otherwise I suggest you learn to use git cherry-pick, particularly the ability to do cherry-pick using a range of commits.
ArduPilot has undergone some major structural changes for 4.1.x, so it isn’t surprising you are hitting issues.
Hey Tridge,
thanks for your effort. I am considering committing my changes in the future.
I was trying to avoid Cherry-Picks because they don’t maintain the connection between the branches. So there are two identical commits in git afterwards but git doesn’t know that they are the same. So it will cause conflicts when merging two branches. Although they can be practical in some cases. And you are right i will use cherry-picking in this case as well. Why did you use cherry-picking so intensively for the 4.1 release? Was there a particular reason?
when preparing for a new major release we pick a time to branch master into a release branch (in this case plane4.1 branch). Then master keeps moving rapidly, but we don’t want to bring everything going into master into the release as it hasn’t had enough testing. So we need to cherry pick just the most stable changes and bug fixes from master into the release branch over the beta period.
You probably want to do an interactive rebase of your branch onto 4.1.0.
Make backups first.