Until you have merge conflict. If someone could explain to me which file contains the conflict markers so I can fix them I'd be really happy. Its not the .gitmodules file.
if it's a merge conflict happening while updating the submodule, then the conflict is inside the working copy of that submodule. Go there and resolve it using the usual tools, commit and commit the updated submodule revision in the parent repository
Except that doesnt work, because that just changes the hash of the submodule (as stored by the supermodule) again. The problem is that the supermodule just stores the hash of the submodule. The only way I found of fixing it was to:
1. Create a new repo.
2. Get the branched submodule.
3. Check that in as head: Note, now HEAD will NOT compile - I've committed broken code.
4. Go back to the original repo.
5. Get HEAD: this pulls the hash I need.
6. Do the merge. The submodule doesn merge, because it has the right hash.
Surely there must be some way to just modify the hash. But I don't know where to change it. I found it in several locations, but I don't know how it works, and hacking my VCS isnt my idea of good sense.
the command you are looking for is git diff. git status will show you which files changed, git diff will show you where the conflicts are in the files during the merge.
I am pretty certain in this situation that git diff claims that the submodule directory itself has somehow been modified from the previous commit hash to the new one. Please recognize that the case here is a merge conflict between two people advancing the commit the submodule points to to different revisions of the subproject, not merge conflicts inside of the subproject (which really should not be happening).
