Re: Rebasing with submodule change causes red herring with --continue

[John Keeping <john@keeping.me.uk>]

On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:
> I have a branch that contains a commit with a single change: A
> submodule pointing to a new SHA1.
> 
> When I rebase this branch onto the tip of its parent branch AND that
> parent branch had modified that same submodule, the rebase stops at
> the commit on my branch that modified the submodule and asks me if I
> want to keep REMOTE or LOCAL. I say LOCAL and notice immediately that
> the submodule is not staged (normally it would be).
> 
> I do:
> 
> $ git add my-submodule
> 
> Then I do:
> 
> $ git rebase --continue
> 
> At this point, it fails asking me if I forgot to stage changes and
> recommends doing --skip. This is normally what you would see if the
> staging area was completely empty, however it isn't, since I see the
> submodule is in there.
> 
> Is this a bug or am I missing a fundamental here? I'm using Git 2.1.0
> on Windows through MSYS. I'll provide more concrete examples if my
> summary of the issue doesn't "ring any bells".

I hit something similar in the past, but it was fixed with commit
a6754cd (rebase -i continue: don't skip commits that only change
submodules, 2012-04-07) so I think you must be hitting a slightly
different problem, although the tests added in that commit look like
they do test the scenario you describe (specifically 'rebase -i continue
with only submodule staged').