Re: How are submodule conflicts resolved during rebase?

From: Robert Dailey <rcdailey.lists@gmail.com>
Date: Apr 28, 2015, 15:19 UTC
Message-ID: <CAHd499Ain-+HwOydC30YDMFFd5rh9_dk7qaRHJe1w4WUTO-_Vw@mail.gmail.com>
In-Reply-To: <CAHd499CSshO-929PF7fiR4hpxd9J=S+XFuE3sdQHFjPvXT_C0w@mail.gmail.com>

On Tue, Apr 28, 2015 at 9:34 AM, Robert Dailey <rcdailey.lists@gmail.com> wrote:

Show 23 quoted lines

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

I also have rerere enabled in my global .gitconfig. Would this result in the behavior above? Resolve first submodule conflict, rebase --continue, then the next one is auto resolved?