How are submodule conflicts resolved during rebase?

> Hey guys,
>
> I'm using Git for Windows 2.3.6. There is a bit of confusion I have
> with regards to how submodule conflicts are resolved/handled during a
> rebase.
>
> 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).
>
> Help is appreciated. Thank you.

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

> 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.
>
> Hope that helps.
>
> Cheers Heiko

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