Re: git rebase --skip

From: Jeff King <peff@peff.net>
Date: Nov 9, 2007, 03:22 UTC
Message-ID: <20071109032227.GA31760@sigill.intra.peff.net>
In-Reply-To: <7vir4cz45z.fsf@gitster.siamese.dyndns.org>

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