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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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').
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]