How do I manage conflicts with git submodules?

Question

I have a git superproject that references several submodules and I am trying to lock down a workflow for the rest of the my project members to work within.

For this question, lets say my superproject is called supery and the submodule is called subby. (Then is a simplification of what I'm trying to do...I'm not actually using the branches for versions, but I thought it would be easiest to lay out as a question.)

My master branch of supery has the tag v1.0 of the git project subby referenced as a submodule. The branch of supery called one.one and changed the reference of the submodule to point to the tag v1.1 of subby.

I can work within each of these branches without a hitch, but if I try to update the one.one branch with changes from the master branch I receive some conflicts and I don't how to resolve them.

Basically after running a git pull . master while in the subby branch, it looks like it creates additional submodules.

Before the pull/merge, I get the desired response from git submodule from the one.one branch:

$ git checkout master
$ git submodule
qw3rty...321e subby (v1.0)
$ git checkout one.one
$ git submodule
asdfgh...456d subby (v1.1)

But after the pull, it adds additional submodules when I run git submodule:

$ git pull . master
Auto-merged schema
CONFLICT (submodule): Merge conflict in subby - needs qu3rty...321e
Automatic merge failed; fix conflicts and then commit the results.

$ git submodule
qw3rty...321e subby (v1.0)
asdfgh...456d subby (v1.1)
zxcvbn...7890 subby (v1.1~1)

How do I delete/ignore the unwanted submodule references and commit my conflicts and changes? Or is there a parameter I can use with my original git pull that will ignore my submodules?

Answer 1

Well, its not technically managing conflicts with submodules (ie: keep this but not that), but I found a way to continue working...and all I had to do was pay attention to my git status output and reset the submodules:

git reset HEAD subby
git commit

That would reset the submodule to the pre-pull commit. Which in this case is exactly what I wanted. And in other cases where I need the changes applied to the submodule, I'll handle those with the standard submodule workflows (checkout master, pull down the desired tag, etc).