How to solve a CONFLICT (submodule) during rebase?

Quaxwilly · January 4, 2021, 1:09pm

After some corrections of my repo with great support of @amilcarlucas I’m struggling with rebase.
I didn’t change anything on submodules and just want to have the latest submodules of upstream/master in my repo. A “git submodule update --init --recursive” didn’t work as expected and a
rebase produced an error: CONFLICT (submodule)

I know how to solve a file-conflict, but I dont’t know how I could solve that submodule-conflict:
2021-01-02 17_45_32-Window

I read different things, but there I couldn’t find an answer:
https://ardupilot.org/dev/docs/git-submodules.html
file:///C:/Program%20Files/Git/mingw64/share/doc/git-doc/git-submodule.html
https://codeinthehole.com/guides/resolving-conflicts-during-a-git-rebase/

(I asked that question in another thread too, but there it’s hidden deep in the conversation)

khancyr · January 4, 2021, 2:51pm

if you didn’t change anything in the submodule, you could just remove its directory (rm -rf modules/mavlink) and then git submodule update --init --recursive back

Quaxwilly · January 4, 2021, 5:35pm

Thank you for the quick reply @khancyr
I tried out your suggestion, but unfortunatelly it’s not working:
delete subdir.pdf (15.6 KB)

It would help me if I could tell the git rebase to accept all green or red lines of conflicts - or better to edit (whatever) and select the wanted.

khancyr · January 4, 2021, 4:56pm

ok so that your branch is changing something in mavlink , are you sure that you aren’t pointing to a specific mavlink revision ?

You should be able to enter into modules/mavlink directory and use git from there to fix the conflict or discard the changes.

Quaxwilly · January 4, 2021, 5:42pm

Ahhhhh yes, it could be possible that @amilcarlucas had a specific revision on his branch (if I remember right he’s working on mavlink) - my branch is a pull from him.
So is there a way to discard all that submodule-changes on my branch and return to the clean current state of upstream/master? (sorry, I’m not so experienced in git)

amilcarlucas · January 4, 2021, 9:24pm

For some strange reason your branch has mavlink commits. The branch I gave you did not have mavlink commits. Please do not make mavlink commits and all will be fine!

Quaxwilly · January 5, 2021, 8:38am

Thank you for clarification @amilcarlucas.
I’m not aware to have changed anything in submodules.
So I will investigate and try to rollback to have clean submodules.
Maybe that’s a good lesson for me.

khancyr · January 5, 2021, 8:42am

hello,

look at here https://ardupilot.org/dev/docs/git-interactive-rebase.html . Using gitk or another git gui, you should find which commit introduce the submodule change, then use git rebase -i master to discard it !

amilcarlucas · January 5, 2021, 11:39am

You need to revert https://github.com/WillyZehnder/ardupilot/commit/c6800ac652049c8b2b4c9b9a7edfdbf9efff7fb9
On the MisRelSep branch

Your MisRelDec branch is fine!

I have now rebased my MisRelDec on top of master from today: https://github.com/amilcarlucas/ardupilot/commits/MisRelDec

Fell free to overwrite your MisRelSep branch with the one from me, using the instructions that I provided you and not missing the step to discard any local mavlink changes!

Quaxwilly · January 5, 2021, 1:56pm

It makes me crazy that mavlink is always pointing to a very old version after “git submodule update --init --recursive”:

So it seems, my mistake happened very early in June last year:

So what would be a sufficient action to fix that?
Is it possible to go back to that version, exclude that two adds of modules/… and push again?

amilcarlucas · January 5, 2021, 2:25pm

You need to change to the branch that I posted. Test it. if it works fine (and it should), delete your old branch, rename my branch to MisRelSep and force push it to github. I already explained you how to do those steps.

amilcarlucas · January 5, 2021, 2:39pm

I just forced pushed MisRelDec into your repo
All should work now, on top of master

You need to do:
delete your local branch: git branch -D MisRelDec
get the one I did : git fetch origin MisRelDec
check it out: git checkout MisRelDec
test it:

git submodule update --init --recursive
./waf configure
./waf copter
...

And if all is fine:

git branch -D MisRelSep
git checkout -b MisRelSep
git push -f origin
git branch -D MisRelDec

amilcarlucas · January 5, 2021, 2:48pm

I can also do these steps for you if you want…you just need to test it.

Quaxwilly · January 6, 2021, 10:28am

Thank you Amilcar - I’ll try it by my own in the evening.

Edit 18:40:
SITL build for all vehicles -> OK -> SITL-Tests tomorrow
Edit 06.01.21 11:30:
MatekF405-Wing-SMR build for all vehicles -> OK
MatekF405-Wing build -> rework necessary because of missing define “MISSION_RELATIVE”

Quaxwilly · January 6, 2021, 10:52am

I stumbled on doing the last steps.
I tend to do
$git push -f --set-upstream origin MisRelSep
but I learned that it’s more wise to ask before

amilcarlucas · January 6, 2021, 12:43pm

Yes, you can do it. Looks good to me

Quaxwilly · January 7, 2021, 10:19am

It works -Yippee - one step more done
Again a big THANK YOU to all that supported me, esp. @amilcarlucas

It would help me (and maybe others) to understand the fixing if you could explain in some words how you have done that “rollback” after my mistake.
Was it just a “git rebase -i master” and splitting/deletion of my bad commits?
Or is there a special way to go back to the normal behaviour (where master fixes the modules-version I guess)?

amilcarlucas · January 7, 2021, 10:21am

It was just a “git rebase -i master” and splitting/deletion of your bad comits.
Just do not commit changes into submodules if you do not mean to