list mirror (unofficial, one of many)
 help / color / Atom feed
From: Stefan Beller <>
Cc: "" <>
Subject: Re: 2.15.1 - merge with submodule output issue
Date: Tue, 30 Jan 2018 14:02:12 -0800
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Jan 30, 2018 at 7:42 AM, FIGADERE, LAURENT
<> 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.

      reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-30 15:42 FIGADERE, LAURENT
2018-01-30 22:02 ` Stefan Beller [this message]

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox