Re: [PATCH v2] submodule merge: update conflict error message
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 12, 2022, 23:30 UTC
- Message-ID
- <xmqqk09l8no3.fsf@gitster.g>
- In-Reply-To
- <CABPp-BHe7wdd3LMYtZ83ZgapvUxzQYcK-3=sdMAD5Ozs4YmKyw@mail.gmail.com>
Elijah Newren <newren@gmail.com> writes:
Show 12 quoted lines
>> 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.