13

We are using submodules and we are new to git.

We often see merge conflicts for the submodules themselves, no files are conflicted, just the submodule. There are multiple versions listed in the output of git submodule summary. We resolve them by running git add <submodule> in the superproject.
But today we had a developer lose a commit of the submodule when she resolved the conflict in this manner.
Does running a git add choose the remote version? Shouldn't the contents of the submodule get merged? If she made changes in the submodule and committed them (which I see), then why would that commit disappear after she ran the pull and resolved the conflict?

Cœur
  • 34,719
  • 24
  • 185
  • 251
user561638
  • 1,199
  • 3
  • 14
  • 26

2 Answers2

12

Your local submodule and the remote submodule have diverged.

git checkout --theirs submodulename

or for your version:

git checkout --ours submodulename

and then commit the changes with git add and commit the changes.

Note: Your shell may add a trailing slash to the submodulename if you tabcomplete, since it is also a subdirectory. If so, you need to delete it or you'll get:

error: pathspec 'submodulename/' did not match any file(s) known to git.
Andrew Wagner
  • 20,197
  • 19
  • 75
  • 95
  • 3
    This isn't working for me: upstream changes the module, and while merging in their changes I tried 'git checkout --theirs ios_src' but in 'git diff origin/dev_ios .' I still see my local oid marked '-dirty' and the new one not marked dirty. I was expecting to see the my local line to be the new oid with a '-dirty' mark. Committing also leaves me with my oid. Going into the modules and explicitly checking the root out, then adding it works, but that's tedious. – android.weasel Jun 27 '16 at 11:13
11

Both file conflicts and submodule conflicts occur when your current branch and the branch-you-want-to-merge-into have diverged.

It merely means an ambiguous situation exists -- you could legitimately want either to "win" in any given case. So, while it may seem "annoying", they merely highlight your rich options to specify what you want (and you must specify what you want). (And, all that programmers do every day is merely to specify detail.)

It seems like the git-add-the-submodule-on-the-superproject should have worked. However, you also had the option to git-checkout-on-the-superproject right away. This is mentioned in this link (resolving submodule conflicts), which talks about the difference between file conflicts and summodule conflicts, and how to resolve them:

http://pacific.mpi-cbg.de/wiki/index.php/Git_Conflicts

charley
  • 5,813
  • 1
  • 32
  • 58
  • 7
    I think the link is not currently working. WebArchive to the rescue: http://web.archive.org/web/20100925080451/http://pacific.mpi-cbg.de/wiki/index.php/Git_Conflicts – Ricardo Sanchez-Saez Nov 28 '12 at 11:35
  • git checkout --theirs or for your version: git checkout --ours – Andrew Wagner May 19 '14 at 11:21
  • 1
    Clarification to your initial statement: The potential conflicted files/submodules must have both changed in both diverged paths. Simply a branch diverging does not mean you will get conflicts. – void.pointer Apr 28 '15 at 14:53