Am 04.02.2014 00:01, schrieb Junio C Hamano: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >> This new option will allow the user to not only update the work tree of >> the superproject according to the merge result but to also update the >> work tree of all initialized submodules (so they match the SHA-1 recorded >> in the superproject). But this commit only adds the option without any >> functionality, that will be added to unpack_trees() in subsequent commits. > > When the two branches of the superproject being merged wants to put > a submodule project to commit A and B, that conflict needs to be > resolved, but if they agree that the submodule project should be at > C (which is different from what the current superproject HEAD has > for the submodule in its gitlink), then we want a checkout of that > commit to happen in that submodule. Makes sense. > > After resolving such a conflict between A and B, who is responsible > to adjust the working tree state of the submodule involved, by the > way? "git merge --continue" does not exist and its moral equivalent > to conclude such an interrupted merge is "git commit". Should it > learn to do "recurse-submodule", or should the user run a separate > "checkout --recurse-submodule"? I think the user needs to sort things out, just like she has to do when a file has a merge conflict. But unfortunately we cannot use conflict markers here, so I'd propose the following: * When merge proposes a merge resolution (which it does today by telling the user "Found a possible merge resolution for the submodule ... [use] git update-index --cacheinfo 160000 ...") that commit should be checked out in the submodule but not staged. Then the user can simply add and commit. * If the merge resolution is not obvious to merge, it leaves the submodule in an unmerged state, the local commit still being checked out. The user has to manually do the merge in the submodule and commits that in the superproject. Does that make sense? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html