From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 03 Feb 2014 23:01:10 GMT
Subject: Re: [WIP/PATCH 4/9] Teach merge the --[no-]recurse-submodules option
Message-ID: <xmqq4n4fdcnd.fsf@gitster.dls.corp.google.com>
In-Reply-To: <52EFF311.1090202@web.de>

Jens Lehmann <Jens.Lehmann@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"?