Re: git rebase --skip

[Jeff King <peff@peff.net>]

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

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