On Tue, Apr 28, 2015 at 01:19:00PM -0500, Robert Dailey wrote: > On Tue, Apr 28, 2015 at 11:49 AM, Heiko Voigt <hvo...@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 -- 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
