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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
