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

From: John Keeping <john@keeping.me.uk>
Date: Apr 10, 2015, 16:44 UTC
Message-ID: <20150410164413.GL21452@serenity.lan>
In-Reply-To: <CAHd499AqCJ5N1GP6mBJZB7-9vWPNjtia1G7PHoSY3d=Zovv7UA@mail.gmail.com>

On Fri, Apr 10, 2015 at 11:30:20AM -0500, Robert Dailey wrote:

Show 25 quoted lines

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