How to solve a CONFLICT (submodule) during rebase?

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:

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

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

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.

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.

1 Like

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)

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!

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.


look at here . Using gitk or another git gui, you should find which commit introduce the submodule change, then use git rebase -i master to discard it !

You need to revert
On the MisRelSep branch

Your MisRelDec branch is fine!

I have now rebased my MisRelDec on top of master from today:

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!

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?

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.

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

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

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

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”

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 :wink:

Yes, you can do it. Looks good to me

It works -Yippee - one step more done :smiley:
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)?

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 :wink:

1 Like