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 160000 ...")
> >   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.


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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to