Re: git rebase --skip

> On 2007.11.07 22:23:10 -0500, Jeff King wrote:
>> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:
>>
>>> I use git-rebase quite regularly, and I haven't used git-rebase --skip
>>> after a failed merge without first resetting the working tree. I was
>>> wondering if it wouldn't make sense to automatically do the reset when
>>> running git-rebase --skip.
>> I have often been annoyed by this behavior, too, and I can't think of
>> any situation where you _wouldn't_ want the reset to happen.  But I
>> would be more comfortable hearing confirmation from others that they
>> can't think of such a situation.
> 
> Let's take this history:
> 
>       C---D---E topic
>      /
>     A---B master
> 
> You then do:
> git rebase master topic
> 
> Now D causes conflicts, because B did a similar change, but not quite
> the same, maybe having a bug. So you want to keep parts of D, but it's
> no longer the same commit semantically and the original commit message
> would be bogus. So you resolve the conflicts and do:
> 
> git commit
> git rebase --skip
> 
> Because you replaced D with a new different commit, instead of really
> just rebasing it. With plain --continue, you'd have to go back and fix
> the commit message once the rebase is complete. And --continue after the
> commit is a no-go, too, because rebase will complain that there's
> nothing left to produce the rebased D commit.
> 
> And now imagine that you forget to commit but instead just --skip.
> Ouch, all the work is lost, time to restart the rebase. With the current
> behaviour, rebase won't just throw away your stuff.
>