Re: How are submodule conflicts resolved during rebase?

[Heiko Voigt <hvoigt@hvoigt.net>]

On Tue, Apr 28, 2015 at 01:19:00PM -0500, Robert Dailey wrote:
> On Tue, Apr 28, 2015 at 11:49 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> > On Tue, Apr 28, 2015 at 09:34:06AM -0500, Robert Dailey wrote:
> >> Suppose I have a branch with 10 commits on it, 3 of those commits
> >> contain a change to the same (and only) submodule in the repository.
> >> When I rebase this branch onto the tip of its parent branch, I get a
> >> conflict in each of the 3 commits because the submodule also changed
> >> on the parent branch since my last rebase.
> >>
> >> I've seen some cases where I am asked to resolve the submodule
> >> conflict with local or remote. I expect this behavior and it isn't
> >> confusing to me. However, I have also seen cases where rebase auto
> >> resolves the conflicted submodule.
> >>
> >> How does Git know to auto resolve some submodule conflicts but not the
> >> others? I find this behavior unpredictable and I haven't found any
> >> documentation on it (I'm giving the git docs the benefit of the doubt
> >> and assuming it's there, since the git docs are very very good).
> >
> > There is some logic for submodule merges, but to prevent false merges
> > only the straight forward case results in a clean merge. In short:
> > Conflicts for submodules are auto resolved when one side is contained in
> > the other and both changes point forward.
> >
> > I.e. when merging A and B in the superproject and the submodule looks
> > like this:
> >
> >         base---*---*---B
> >         \             /
> >          *---A---*---*
> >
> > It will result in a clean merge in the superproject.
> >
> > If there is a common commit that contains both sides but that commit is
> > not part of any side in the superproject the merge will fail but suggest
> > that commit as a conflict resolution.
> >
> So if I understand this correctly, you are saying that during a rebase
> if it sees a potential conflict for a submodule in the commit being
> rebased, it will inspect the ancestry of the actual commits in the
> submodule logs?

Yes that is correct.


> For a rebase, does this mean that the local (latest SHA1 from the
> submodule in the target branch of the rebase) submodule commit must be
> reachable from the remote (SHA1 contained in the diff of the commit
> currently being rebased) submodule commit?

I does not matter which is reachable from which but yes one has to be
reachable from the other.

> I just want to make sure this is the logic. Thanks for explaining,
> still trying to wrap my head around it.

Yeah submodule things tend become complicated to think about at times.

Cheers Heiko