mailing list mirror (one of many)
 help / Atom feed
From: Stefan Beller <>
To: David Turner <>
Cc: git <>,
Subject: Re: submodule modify/delete wrong message
Date: Mon, 11 Dec 2017 12:27:22 -0800
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Dec 4, 2017 at 1:39 PM, David Turner <> wrote:
> When merging with a submodule modify/delete conflict (i.e. I've deleted
> the submodule, and I'm merging in a branch that modified it), git lies
> about what it is doing:
> "CONFLICT (modify/delete): submodule deleted in HEAD and modified in
> submodules.

Up to here the error message sounds correct, still?

> Version submodules of submodule left in tree at
> submodule~submodules.
> Automatic merge failed; fix conflicts and then commit the result."

This sounds as if the code assumed to handle only files.

> In fact, the working tree does not contain anything named
> 'submodule~submodules'.
> In addition, I would ordinarily resolve a conflict like this by using
> 'git rm'. Here, this gives a warning:
> $ git rm submodule
> submodule: needs merge

(Regarding submodule merges in general:)

Uh. We cannot add merge markers to a submodule or such.
More importantly we'd have to ask the question if the merge conflict
is on the superproject level (Choose one of the commits of the submodule)
or on the submodule level (perform a merge in the submodule between the
two commits) or some hybrid approach thereof.

> rm 'submodule'
> warning: Could not find section in .gitmodules where path=submodule

The deletion of the submodule removed the .gitmodules entry, and the
merge of the .gitmodules file presumably went fine. :/

I assume we need a special merge driver for the .gitmodules file to keep
the submodule around when it is in at least one side.

> Git's behavior here is significantly better than liggit2's (which tries
> to check out 'submodule' as if it were a blob, and fails to do so), but
> it's still confusing.
> It's not clear to me what the correct behavior is here.  Maybe it's
> sufficient to just fix the message?

I think the first step is to fix the message to reflect reality.

As alluded to above, I don't know what the correct merge
behavior is (and where to put 'conflict markers').


  reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 21:39 David Turner
2017-12-11 20:27 ` Stefan Beller [this message]
2017-12-11 20:35   ` David Turner

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 mailing list mirror (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