Re: [WIP/PATCH 4/9] Teach merge the --[no-]recurse-submodules option

From: Jens Lehmann <jens.lehmann@web.de>
Date: Feb 7, 2014, 21:23 UTC
Message-ID: <52F54ED7.2010302@web.de>
In-Reply-To: <xmqq4n4fdcnd.fsf@gitster.dls.corp.google.com>

Am 04.02.2014 00:01, schrieb Junio C Hamano:

Show 21 quoted lines

> 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"?

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?