git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* submodule modify/delete wrong message
@ 2017-12-04 21:39 David Turner
  2017-12-11 20:27 ` Stefan Beller
  0 siblings, 1 reply; 3+ messages in thread
From: David Turner @ 2017-12-04 21:39 UTC (permalink / raw)
  To: git; +Cc: brock.peabody

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. Version submodules of submodule left in tree at
submodule~submodules.
Automatic merge failed; fix conflicts and then commit the result."

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
rm 'submodule'
warning: Could not find section in .gitmodules where path=submodule

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?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: submodule modify/delete wrong message
  2017-12-04 21:39 submodule modify/delete wrong message David Turner
@ 2017-12-11 20:27 ` Stefan Beller
  2017-12-11 20:35   ` David Turner
  0 siblings, 1 reply; 3+ messages in thread
From: Stefan Beller @ 2017-12-11 20:27 UTC (permalink / raw)
  To: David Turner; +Cc: git, brock.peabody

On Mon, Dec 4, 2017 at 1:39 PM, David Turner <novalis@novalis.org> 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').

Stefan

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: submodule modify/delete wrong message
  2017-12-11 20:27 ` Stefan Beller
@ 2017-12-11 20:35   ` David Turner
  0 siblings, 0 replies; 3+ messages in thread
From: David Turner @ 2017-12-11 20:35 UTC (permalink / raw)
  To: Stefan Beller; +Cc: git, brock.peabody

On Mon, 2017-12-11 at 12:27 -0800, Stefan Beller wrote:
> On Mon, Dec 4, 2017 at 1:39 PM, David Turner <novalis@novalis.org>
> 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?

Yep!

> > 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.

This assumption is unfortunately very common -- I just filed a PR to
fix an instance of this in libgit2.

> > 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.

Yeah, that's a tricky thing in general.  In this case, tho, the
submodule is being removed, so git rm should work.

> > 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. :/

Indeed.

> 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').

The only case we need 'conflict markers' is in the
{add,modify}/{add,modify} case (with different versions on each side). 
The delete/* and */delete case can be handled more simply.  We might
not want to do this until we can handle all cases -- but personally, I
think a half-solution is better than a non-solution.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-12-11 20:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-04 21:39 submodule modify/delete wrong message David Turner
2017-12-11 20:27 ` Stefan Beller
2017-12-11 20:35   ` David Turner

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).