Re: [WIP/PATCH 4/9] Teach merge the --[no-]recurse-submodules option
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 3, 2014, 23:01 UTC
- Message-ID
- <xmqq4n4fdcnd.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <52EFF311.1090202@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
Show 5 quoted lines
> 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"?