git.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).