{"thread":{"id":"39181","subject":"How are submodule conflicts resolved during rebase?","startedAt":"2015-04-28T14:34:06Z","lastAt":"2015-04-28T19:21:22Z","messageCount":5,"participants":["Robert Dailey","Heiko Voigt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"260127","messageId":"CAHd499CSshO-929PF7fiR4hpxd9J=S+XFuE3sdQHFjPvXT_C0w@mail.gmail.com","threadId":"39181","inReplyTo":null,"subject":"How are submodule conflicts resolved during rebase?","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2015-04-28T14:34:06Z","receivedAt":"2015-04-28T14:34:06Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"Hey guys,\n\nI'm using Git for Windows 2.3.6. There is a bit of confusion I have\nwith regards to how submodule conflicts are resolved/handled during a\nrebase.\n\nSuppose I have a branch with 10 commits on it, 3 of those commits\ncontain a change to the same (and only) submodule in the repository.\nWhen I rebase this branch onto the tip of its parent branch, I get a\nconflict in each of the 3 commits because the submodule also changed\non the parent branch since my last rebase.\n\nI've seen some cases where I am asked to resolve the submodule\nconflict with local or remote. I expect this behavior and it isn't\nconfusing to me. However, I have also seen cases where rebase auto\nresolves the conflicted submodule.\n\nHow does Git know to auto resolve some submodule conflicts but not the\nothers? I find this behavior unpredictable and I haven't found any\ndocumentation on it (I'm giving the git docs the benefit of the doubt\nand assuming it's there, since the git docs are very very good).\n\nHelp is appreciated. Thank you.\n"},{"id":"260129","messageId":"CAHd499Ain-+HwOydC30YDMFFd5rh9_dk7qaRHJe1w4WUTO-_Vw@mail.gmail.com","threadId":"39181","inReplyTo":"CAHd499CSshO-929PF7fiR4hpxd9J=S+XFuE3sdQHFjPvXT_C0w@mail.gmail.com","subject":"Re: How are submodule conflicts resolved during rebase?","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2015-04-28T15:19:54Z","receivedAt":"2015-04-28T15:19:54Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Tue, Apr 28, 2015 at 9:34 AM, Robert Dailey wrote:\n> Hey guys,\n>\n> I'm using Git for Windows 2.3.6. There is a bit of confusion I have\n> with regards to how submodule conflicts are resolved/handled during a\n> rebase.\n>\n> Suppose I have a branch with 10 commits on it, 3 of those commits\n> contain a change to the same (and only) submodule in the repository.\n> When I rebase this branch onto the tip of its parent branch, I get a\n> conflict in each of the 3 commits because the submodule also changed\n> on the parent branch since my last rebase.\n>\n> I've seen some cases where I am asked to resolve the submodule\n> conflict with local or remote. I expect this behavior and it isn't\n> confusing to me. However, I have also seen cases where rebase auto\n> resolves the conflicted submodule.\n>\n> How does Git know to auto resolve some submodule conflicts but not the\n> others? I find this behavior unpredictable and I haven't found any\n> documentation on it (I'm giving the git docs the benefit of the doubt\n> and assuming it's there, since the git docs are very very good).\n>\n> Help is appreciated. Thank you.\n\nI also have rerere enabled in my global .gitconfig. Would this result\nin the behavior above? Resolve first submodule conflict, rebase\n--continue, then the next one is auto resolved?\n"},{"id":"260132","messageId":"20150428164904.GA4477@sandbox-ub1410","threadId":"39181","inReplyTo":"CAHd499CSshO-929PF7fiR4hpxd9J=S+XFuE3sdQHFjPvXT_C0w@mail.gmail.com","subject":"Re: How are submodule conflicts resolved during rebase?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2015-04-28T16:49:04Z","receivedAt":"2015-04-28T16:49:04Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Apr 28, 2015 at 09:34:06AM -0500, Robert Dailey wrote:\n> Suppose I have a branch with 10 commits on it, 3 of those commits\n> contain a change to the same (and only) submodule in the repository.\n> When I rebase this branch onto the tip of its parent branch, I get a\n> conflict in each of the 3 commits because the submodule also changed\n> on the parent branch since my last rebase.\n> \n> I've seen some cases where I am asked to resolve the submodule\n> conflict with local or remote. I expect this behavior and it isn't\n> confusing to me. However, I have also seen cases where rebase auto\n> resolves the conflicted submodule.\n> \n> How does Git know to auto resolve some submodule conflicts but not the\n> others? I find this behavior unpredictable and I haven't found any\n> documentation on it (I'm giving the git docs the benefit of the doubt\n> and assuming it's there, since the git docs are very very good).\n\nThere is some logic for submodule merges, but to prevent false merges\nonly the straight forward case results in a clean merge. In short:\nConflicts for submodules are auto resolved when one side is contained in\nthe other and both changes point forward.\n\nI.e. when merging A and B in the superproject and the submodule looks\nlike this:\n\n\tbase---*---*---B\n\t\\ /\n\t *---A---*---*\n\nIt will result in a clean merge in the superproject.\n\nIf there is a common commit that contains both sides but that commit is\nnot part of any side in the superproject the merge will fail but suggest\nthat commit as a conflict resolution.\n\nHope that helps.\n\nCheers Heiko\n"},{"id":"260133","messageId":"CAHd499AMKd4aRfDxraArmBGE5eeAhTHQKPbAhcXC-kfPEJPtYQ@mail.gmail.com","threadId":"39181","inReplyTo":"20150428164904.GA4477@sandbox-ub1410","subject":"Re: How are submodule conflicts resolved during rebase?","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2015-04-28T18:19:00Z","receivedAt":"2015-04-28T18:19:00Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Tue, Apr 28, 2015 at 11:49 AM, Heiko Voigt wrote:\n> On Tue, Apr 28, 2015 at 09:34:06AM -0500, Robert Dailey wrote:\n>> Suppose I have a branch with 10 commits on it, 3 of those commits\n>> contain a change to the same (and only) submodule in the repository.\n>> When I rebase this branch onto the tip of its parent branch, I get a\n>> conflict in each of the 3 commits because the submodule also changed\n>> on the parent branch since my last rebase.\n>>\n>> I've seen some cases where I am asked to resolve the submodule\n>> conflict with local or remote. I expect this behavior and it isn't\n>> confusing to me. However, I have also seen cases where rebase auto\n>> resolves the conflicted submodule.\n>>\n>> How does Git know to auto resolve some submodule conflicts but not the\n>> others? I find this behavior unpredictable and I haven't found any\n>> documentation on it (I'm giving the git docs the benefit of the doubt\n>> and assuming it's there, since the git docs are very very good).\n>\n> There is some logic for submodule merges, but to prevent false merges\n> only the straight forward case results in a clean merge. In short:\n> Conflicts for submodules are auto resolved when one side is contained in\n> the other and both changes point forward.\n>\n> I.e. when merging A and B in the superproject and the submodule looks\n> like this:\n>\n> base---*---*---B\n> \\ /\n> *---A---*---*\n>\n> It will result in a clean merge in the superproject.\n>\n> If there is a common commit that contains both sides but that commit is\n> not part of any side in the superproject the merge will fail but suggest\n> that commit as a conflict resolution.\n>\n> Hope that helps.\n>\n> Cheers Heiko\n\nSo if I understand this correctly, you are saying that during a rebase\nif it sees a potential conflict for a submodule in the commit being\nrebased, it will inspect the ancestry of the actual commits in the\nsubmodule logs? For a rebase, does this mean that the local (latest\nSHA1 from the submodule in the target branch of the rebase) submodule\ncommit must be reachable from the remote (SHA1 contained in the diff\nof the commit currently being rebased) submodule commit?\n\nI just want to make sure this is the logic. Thanks for explaining,\nstill trying to wrap my head around it.\n"},{"id":"260135","messageId":"20150428192122.GA2933@sandbox-ub1410","threadId":"39181","inReplyTo":"CAHd499AMKd4aRfDxraArmBGE5eeAhTHQKPbAhcXC-kfPEJPtYQ@mail.gmail.com","subject":"Re: How are submodule conflicts resolved during rebase?","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2015-04-28T19:21:22Z","receivedAt":"2015-04-28T19:21:22Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Apr 28, 2015 at 01:19:00PM -0500, Robert Dailey wrote:\n> On Tue, Apr 28, 2015 at 11:49 AM, Heiko Voigt wrote:\n> > On Tue, Apr 28, 2015 at 09:34:06AM -0500, Robert Dailey wrote:\n> >> Suppose I have a branch with 10 commits on it, 3 of those commits\n> >> contain a change to the same (and only) submodule in the repository.\n> >> When I rebase this branch onto the tip of its parent branch, I get a\n> >> conflict in each of the 3 commits because the submodule also changed\n> >> on the parent branch since my last rebase.\n> >>\n> >> I've seen some cases where I am asked to resolve the submodule\n> >> conflict with local or remote. I expect this behavior and it isn't\n> >> confusing to me. However, I have also seen cases where rebase auto\n> >> resolves the conflicted submodule.\n> >>\n> >> How does Git know to auto resolve some submodule conflicts but not the\n> >> others? I find this behavior unpredictable and I haven't found any\n> >> documentation on it (I'm giving the git docs the benefit of the doubt\n> >> and assuming it's there, since the git docs are very very good).\n> >\n> > There is some logic for submodule merges, but to prevent false merges\n> > only the straight forward case results in a clean merge. In short:\n> > Conflicts for submodules are auto resolved when one side is contained in\n> > the other and both changes point forward.\n> >\n> > I.e. when merging A and B in the superproject and the submodule looks\n> > like this:\n> >\n> > base---*---*---B\n> > \\ /\n> > *---A---*---*\n> >\n> > It will result in a clean merge in the superproject.\n> >\n> > If there is a common commit that contains both sides but that commit is\n> > not part of any side in the superproject the merge will fail but suggest\n> > that commit as a conflict resolution.\n> >\n> So if I understand this correctly, you are saying that during a rebase\n> if it sees a potential conflict for a submodule in the commit being\n> rebased, it will inspect the ancestry of the actual commits in the\n> submodule logs?\n\nYes that is correct.\n\n\n> For a rebase, does this mean that the local (latest SHA1 from the\n> submodule in the target branch of the rebase) submodule commit must be\n> reachable from the remote (SHA1 contained in the diff of the commit\n> currently being rebased) submodule commit?\n\nI does not matter which is reachable from which but yes one has to be\nreachable from the other.\n\n> I just want to make sure this is the logic. Thanks for explaining,\n> still trying to wrap my head around it.\n\nYeah submodule things tend become complicated to think about at times.\n\nCheers Heiko\n"}]}