Re: [WIP/PATCH 4/9] Teach merge the --[no-]recurse-submodules option
Am 04.02.2014 00:01, schrieb Junio C Hamano: 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? 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 16 ...) 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP/PATCH 4/9] Teach merge the --[no-]recurse-submodules option
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 16 ...) 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
Re: [git] Re: [WIP/PATCH 4/9] Teach merge the --[no-]recurse-submodules option
On Fri, Feb 07, 2014 at 02:00:23PM -0800, Junio C Hamano wrote: 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 16 ...) that commit should be checked out in the submodule but not staged. Then the user can simply add and commit. … … For the former, add and commit at the top-level makes perfect sense, … This still works if the merge issue is in a grandchild submodule, but it's going to be a bit tedious if the user has to add-and-commit at each level from the troublesome sub-sub-…-module on up to the top-level superproject. I can't think of a cleaner solution though. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [WIP/PATCH 4/9] Teach merge the --[no-]recurse-submodules option
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
