Re: git rebase --skip

From: Jeff King <peff@peff.net>
Date: Nov 8, 2007, 23:16 UTC
Message-ID: <20071108231632.GC29840@sigill.intra.peff.net>
In-Reply-To: <20071108104403.GB31187@atjola.homenet>

On Thu, Nov 08, 2007 at 11:44:03AM +0100, Björn Steinbrink wrote:

Show 11 quoted lines

> > 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 ;-)

Personally, I don't see the point of a --force option; it turns your work flow from:

  1. git-rebase --skip
  2. Oops, I guess I have to reset.
  3. git-reset --hard; git-rebase --skip

to:

  1. same as above
  2. same as above
  3. git-rebase --force --skip

I guess it's a little bit easier to explain to new users, but it in no way eliminates the annoyance of "I expected this to work, and it didn't, so now I have to think about what happened and enter another command."

AIUI, Andreas's proposal is not so much DWIM as "do the obvious thing, but include a safety valve to prevent throwing away work." Is there actually a case where it would not have the desired effect?

-Peff