On Fri, Feb 07, 2014 at 02:00:23PM -0800, Junio C Hamano wrote: > Jens Lehmann <Jens.Lehmann@xxxxxx> 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. Cheers, Trevor -- 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