Re: git rebase --skip

[Jeff King <peff@peff.net>]

On Thu, Nov 08, 2007 at 03:52:08PM -0800, Junio C Hamano wrote:

> The user is explicitly saying --skip, so I do not think it is
> dangerous even if we unconditionally did "reset --hard" at that
> point.

Sure, I think the complaint is not that "reset --hard" is the wrong
behavior, but that people are prone to type --skip in error. Right now
we handle that error in a data-preserving way (we complain, and the user
has to think and issue a "throw away this data" command), but automatic
reset is less safe (even though there are fewer times when somebody
meant to commit instead of just reset, the consequences are harder to
recover from).

I've never personally run into this, but I think it is a reasonable
thing to think about, and if it is easy to add an additional safety
valve (either stashing the index/wt state, or checking before automatic
"reset --hard" whether any work has been done towards resolving), then
we probably should.

So I am fine with the original patch (unconditional reset --hard), but
it would be nice to see the people who care submit concrete proposals
for such a safety valve.

> Or we could introduce a new option "--drop" (that's "drop the
> current commit and continue") to do so, if people find that the
> word "skip" does not sound like a scary destructive operation.

I don't think the problem is "users don't realize how scary --skip can
be", but rather "I use --skip to resolve this situation 99% of the time,
so in the other 1%, I soetimes use it accidentally."

-Peff