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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
