Re: git rebase --skip

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2007.11.08 11:32:08 +0100, Andreas Ericsson wrote:
> Björn Steinbrink wrote:
>> 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.
>>
>
> How about if the state to skip was stashed, the patch reapplied and the
> differences compared. If they were identical, go ahead and force the
> reset --hard, otherwise abort. That way, --skip will dwim only when
> it's safe, and all the lost work can be automagically created by
> just re-applying the patch again?

I'd prefer the --force option suggested in some other mail. Maybe I'm
just not manly enough, but messing up a rebase can mean lots of
duplicated work, so I'm rather happy with no dwim at all. Maybe for the
real manly users out there, add a rebase.alwaysForce option so they can
laugh at me for not using that ;-)

Björn