Mbed-os: Merge conflicts when updating mbed-os (5.9->5.10)

[daniel-cesarini-tridonic-com]

Description

We are trying to update from 5.9.7 to 5.10.2, we did some local modifications to the mbed-os, so that we need always to merge in the newer versions. Turns out that there are plenty of merge conflicts between 5.9 and 5.10, that are coming directly from the upstream codebase: e.g. the merge of 5.9 into latest master is https://github.com/ARMmbed/mbed-os/pull/8581

Would it be possible for ARM to do this kind of forward conflict resolution as part of the development of the OS?

Issue request type

[ ] Question
[x] Enhancement
[ ] Bug

[kjbracey-arm]

Hi Daniel. This sort of operation is painful - you're mixing cherry-picking and merging, and Git isn't good at this.

There are a few possible approaches here.

1) Avoid mixing cherry-picking and merging by replaying your local changes by rebasing them on 5.10.2.

    git checkout our_fork
    git rebase mbed-os-5.9.7 --onto mbed-os-5.10.2

This might be easiest if your changes are few.

2) Maybe too late now, and a bit fiddly and hard to explain, but have your local changes always made first to a master version of mbed-os (eg 5.9.0), then your working tree is a merge of 5.x.0 with the latest patch 5.x.y. When you merge 5.10.0 into your modified 5.9.0, there would be no conflicts, as it's a pure merge history. Effectively you throw away the merge of the mbed-os-5.9 maintenance branch, and switch to a new based-on-5.10 branch.

3) Possibly the best option for where you are now - make a dummy merge to tell Git that "5.10.2 already has everything from 5.9.7".

     # Create a working branch for the merge
     git checkout -b mbed-os-5.10-merge mbed-os-5.10.2
     # "Merge" 5.9.7 into 5.10.2, indicating to take nothing - "5.10.2 includes 5.9.7"
     git merge mbed-os-5.9.7 -s ours
     # Checkout out our fork
     git checkout our_fork
     # Merge in the prepared 5.10.2
     git merge mbed-os-5.10-merge

At this point the recursive merge strategy should be able to deduce that the cherry-picks in "our_fork" from 5.9.7 are already accounted for in 5.10.2 and not cause conflicts.

We could conceivably do such dummy merges at our end, but would make a mess of the history for people who don't need them, and they can always be done externally. I recall doing similar with a Linux 3.4->3.10 upgrade for Android devices in the past.

[daniel-cesarini-tridonic-com]

@kjbracey-arm thank you for the extensive and quick reply.
We will try out your suggestions and report on the results.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-122

[cmonr]

@daniel-cesarini-tridonic-com Were y'all able to sort this out on your end?

[daniel-cesarini-tridonic-com]

Tridonic internal communication:
FYI: @markus-becker-tridonic-com @javier-moreno-tridonic-com @andreas-myka-tridonic-com

[daniel-cesarini-tridonic-com]

@cmonr we still need a little bit of time.

[cmonr]

@daniel-cesarini-tridonic-com Do you still need more time to continue investigating this?

[daniel-cesarini-tridonic-com]

@cmonr thank you for your patience. We are currently doing the migration to the newer version of mbed, and the process is still not finished, so in order to tell you whether we are fine with the solution / approach you proposed it will take us still more time.
If it is an issue for you to have this issue open on your side, feel free to close it. We are tracking it internally and will report in this (reopen?) or in another one (new) issue.

[cmonr]

@daniel-cesarini-tridonic-com Gotcha. Thanks for the heads up.

We do track these issues internally. I'll go ahead and close this for now. Feel free to reopen or open a new issue when an update is available.