On 2007.11.08 11:32:08 +0100, Andreas Ericsson wrote: > Björn Steinbrink wrote: >> On 2007.11.07 22:23:10 -0500, Jeff King wrote: >>> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote: >>> >>>> I use git-rebase quite regularly, and I haven't used git-rebase --skip >>>> after a failed merge without first resetting the working tree. I was >>>> wondering if it wouldn't make sense to automatically do the reset when >>>> running git-rebase --skip. >>> I have often been annoyed by this behavior, too, and I can't think of >>> any situation where you _wouldn't_ want the reset to happen. But I >>> would be more comfortable hearing confirmation from others that they >>> can't think of such a situation. >> >> Let's take this history: >> >> C---D---E topic >> / >> A---B master >> >> You then do: >> git rebase master topic >> >> Now D causes conflicts, because B did a similar change, but not quite >> the same, maybe having a bug. So you want to keep parts of D, but it's >> no longer the same commit semantically and the original commit message >> would be bogus. So you resolve the conflicts and do: >> >> git commit >> git rebase --skip >> >> Because you replaced D with a new different commit, instead of really >> just rebasing it. With plain --continue, you'd have to go back and fix >> the commit message once the rebase is complete. And --continue after the >> commit is a no-go, too, because rebase will complain that there's >> nothing left to produce the rebased D commit. >> >> And now imagine that you forget to commit but instead just --skip. >> Ouch, all the work is lost, time to restart the rebase. With the current >> behaviour, rebase won't just throw away your stuff. >> > > 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 ;-) Björn - 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
