On Tue, Jan 30, 2018 at 7:42 AM, FIGADERE, LAURENT
<laurent.figadere@xxxxxxxx> wrote:
> Dear git,
>
> I use since few weeks now git 2.15.1.
>
> I did few trials but please find here my outputs.
>
> To reproduce:
> Use a top module git which include a submodule
> First step: from a work area, I changed selected version of submodule in master branch.
> Then git add + git commit + git push
> A new commit on master branch has been published on my origin repository with the version v1.2 of submodule
>
> Second step: in my second workarea, I created a user branch mybranch, then selected another release of submodule
> I added the update and then commit in mybranch.
> A new commit with release v2.0 of submodule is in my last SHA1 of mybranch
>
> Last step: in the second workarea, in mybranch, I first run ‘git fetch’ and then ‘git merge origin/master’
> I got a CONFLICT message of course due to the 2 different versions of submodule.
> Here the message:
> warning: Failed to merge submodule submodule (commits don't follow merge-base)
> Auto-merging submodule
> CONFLICT (submodule): Merge conflict in submodule
> Automatic merge failed; fix conflicts and then commit the result.
>
> Now I thought that the command ‘git submodule’ provided an output with both versions of modules (local and remote).
> But this is not the case in my environment:
> [15:20:10] $ git submodule status
> U0000000000000000000000000000000000000000 submodule
>
> And when I run the mergetool command I have this output:
> [14:54:41] $ git mergetool
> Merging:
> submodule
> Submodule merge conflict for 'submodule':
> {local}: submodule commit 08f86f2404d9f8f616262971a3127e69f39f9d11
> {remote}: submodule commit b3dd6fde4f02258b88ad0b2dba6474c126b499f7
> Use (l)ocal or (r)emote, or (a)bort?
>
> So, it means it’s not usefull to determine which version has to be selected.
> Is it a bug or perhaps I make something wrong?
It's not a bug, but the real feature has not been implemented yet.
