All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: "Björn Steinbrink" <B.Steinbrink@gmx.de>
Cc: Jeff King <peff@peff.net>, Mike Hommey <mh@glandium.org>,
	git@vger.kernel.org
Subject: Re: git rebase --skip
Date: Thu, 08 Nov 2007 11:32:08 +0100	[thread overview]
Message-ID: <4732E5A8.3020101@op5.se> (raw)
In-Reply-To: <20071108102412.GA31187@atjola.homenet>

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?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

  reply	other threads:[~2007-11-08 10:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-07 22:21 git rebase --skip Mike Hommey
2007-11-07 22:48 ` Johannes Schindelin
2007-11-08  3:23 ` Jeff King
2007-11-08  3:31   ` Jakub Narebski
2007-11-08 10:24   ` Björn Steinbrink
2007-11-08 10:32     ` Andreas Ericsson [this message]
2007-11-08 10:44       ` Björn Steinbrink
2007-11-08 23:16         ` Jeff King
2007-11-08 23:52           ` Junio C Hamano
2007-11-09  1:09             ` Björn Steinbrink
2007-11-09  3:22             ` Jeff King
2007-11-09 10:59               ` Johannes Schindelin
2007-11-09 16:19                 ` J. Bruce Fields
2007-11-09 16:26                   ` J. Bruce Fields
2007-11-09 17:20                 ` Jeff King
2007-11-08 18:43     ` Daniel Barkalow
2007-11-08 19:16       ` Mike Hommey
2007-11-08 19:22         ` Mike Hommey
2007-11-08 23:01         ` Johannes Schindelin
2007-11-08  7:03 ` [PATCH] Do git reset --hard HEAD when using " Mike Hommey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4732E5A8.3020101@op5.se \
    --to=ae@op5.se \
    --cc=B.Steinbrink@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=mh@glandium.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.