Jens Lehmann <> 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
More majordomo info at

Reply via email to