Jens Lehmann <jens.lehm...@web.de> 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"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
