Re: [PATCH v2] submodule merge: update conflict error message

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

>> Git is left in a conflicted state, which requires the user to:
>>  1. merge submodules
>>  2. add submodules changes to the superproject
>>  3. merge superproject
>
> I think we may need to tweak these steps a bit:
>
>    1. merge submodules OR update submodules to an already existing
> commit that reflects the merge (i.e. as submodules they may well be
> independently actively developed.  Someone may have already merged the
> appropriate branch/commit and the already extant merges should be used
> in preference to creating new ones.)

That is a very good point.

I suspect we should encourage users to find an existing merge, and
possibly even discourage them from creating a new one on their own.
There may not be much point in creating the same merge of identical
parent commits with the same result that only has different
metadata.

It may be tempting to argue that an existing merge in a submodule
and the merge you are creating now are made in different context
because the superproject merges that necessitate thse submodule
merges are different, but I doubt that is a healthy argument.  A
commit in the submodule should be able to explain its reason to
exist on its own---after all, the superproject may know which
submodules are used for what purpose, but a submodule does not have
to know where it is used, and that is how it is made more reusable.

>    2. <just as you said>
>    3. FINISH merging the superproject (i.e. don't redo the merge)

Yes, exactly.  FWIW, an earlier draft was telling users to abort the
merge in the first step, and its review corrected it.  1 and 2 are
to be done in the context of the interrupted superproject merge, so
its logical consequence is to conclude the merge at step 3.