I'm going to answer my own question:

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

git reset HEAD subby
git commit

That would reset the submodule to the pre-pull commit for the current
branch. 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).

On May 6, 3:00 pm, Tyler <tsil...@gmail.com> wrote:
> I'm trying to merge two branches of my superproject that each have the
> same submodule, but have different branches referenced within the
> submodule. When I merge, I receive conflicts. And it looks like it
> adds additional submodules.
> How do I handle conflicts with submodules? With normal/file conflicts,
> I can edit the offending files, use git mergetool, add/rm/commit using
> standard git conventions, etc. But I have no clue how to wrangle
> submodule conflicts.
> ----------
> $ git checkout master
> $ git submodule
> qw3rty...321e subby (v1.0)
> $ git checkout branch_uno
> $ git submodule
> asdfgh...456d subby (v1.1)
> ----------
> ----------
> $ 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)
> ----------
> It looks like it keeps the subby branch (v1.1) from the superproject
> branch_uno, then fetches the master's subby branch (v1.0) and then
> also creates a merge of both (v1.1~1).
> In this case, I would like to say, keep the original submodule and
> dump the other two.
> I can't even find where these *new* submodules are recorded in
> the .git directory. My .git/config and .gitmodules are the same as
> they were before the merge. Where does git store the SHA for each
> submodule?
> (And this example may seem a little wonky in execution. I think the
> standard workflow would be to create a new branch for the new
> submodule version and merge back into the master. But I am trying to
> set up some branches for differing versions of the submodules and I
> really want to keep the submodules branches intact and only bring the
> changes of the superproject from branch to branch. If I could do a
> merge and ignore the submodules, I would be content...for now. (And
> cherry-picking would be a major chore with our current branch system
> ftr.))
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to