Re: git rebase --skip

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Nov 8, 2007, 10:24 UTC
Message-ID: <20071108102412.GA31187@atjola.homenet>
In-Reply-To: <20071108032308.GA5638@sigill.intra.peff.net>

On 2007.11.07 22:23:10 -0500, Jeff King wrote:

Show 11 quoted lines

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

Björn