> Hmph. Is 1. necessary? I just tested it and it is not, so I do agree recommending to abort the merge is unnecessary/bad advice. How does this sound? Failed to merge submodule <submodule> CONFLICT (submodule): Merge conflict in <submodule> Automatic merge failed; recursive merging with submodules is currently not supported. To manually merge, merge conflicted submodules first before merging the superproject. On Mon, Jun 6, 2022 at 5:48 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Calvin Wan <calvinwan@xxxxxxxxxx> writes: > > > When attempting to do a non-fast-forward merge in a project with > > conflicts in the submodules, the merge fails and git prints the > > following error: > > > > Failed to merge submodule <submodules> > > CONFLICT (submodule):Merge conflict in <submodule> > > Automatic merge failed; fix conflicts and then commit the result. > > > > Git is left in a conflicted state, which requires the user to: > > 1. abort the merge > > 2. merge submodules > > 3. merge superproject > > These steps are non-obvious for newer submodule users to figure out > > Hmph. Is 1. necessary? > > IOW, based on the information we already have (we may not be > surfacing, which can be corrected), wouldn't it be easier to instead > (A) go to submodule and make a merge and then (B) come back to the > superproject, "git add <submodule" to record the result of submodule > merge, and say "git commit" to conclude? > > The thing I am worried most about is that you may be throwing away > information that would help the user by aborting the superproject > merge. Before doing so, you have stage #2 and stage #3 of the > submodule commit, so which commits in the submodule you need to > merge in (A) above should be fairly clear. If you abort the merge > first, how does the user know which commits in the submodule the > user needs to merge? > > > The error message is based off of what would happen when `merge > > --recurse-submodules` is eventually supported > > OK. > > > Failed to merge submodule <submodule> > > CONFLICT (submodule): Merge conflict in <submodule> > > Automatic merge failed; recursive merging with submodules is currently > > not supported. To manually merge, the following steps are recommended: > > - abort the current merge > > - merge submodules individually > > - merge superproject > > Again, I am not sure about the recommendation. The message saying > "currently not supported" I think is a good idea. > > > I considered automatically aborting the merge if git detects the merge > > failed because of a submodule conflict, however, doing so causes a > > significant amount of tests in `t7610-mergetool.sh` (and some other test > > scripts as well) to fail, suggesting users have come to expect this > > state and have their workarounds with `git mergetool` > > With or without test failures, my gut feeling sais that it cannot be > a good idea to automatically abort the merge, without first grabbing > some information out of the conflicted state. > > Thanks.
