Jens Lehmann <jens.lehm...@web.de> writes: > 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?
The latter one does not worry me too much. For the former, "add and commit" at the top-level makes perfect sense, and the "commit should be checked out in the submodule" is a necessary step to sanity-check and prepare for that "add and commit" step, but what does "checked out in the submodule" exactly mean? Do we detach the HEAD at the commit? Do we advance the tip of the branch of the submodule to that commit? Do we know/require/care if such a move always fast-forwards? -- 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
