Re: git rebase --skip

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Nov 8, 2007, 18:43 UTC
Message-ID: <Pine.LNX.4.64.0711081332550.29952@iabervon.org>
In-Reply-To: <20071108102412.GA31187@atjola.homenet>

On Thu, 8 Nov 2007, Björn Steinbrink wrote:

Show 29 quoted lines

> 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

I guess that works, and nothing else presently does. But I don't think that's at all intuitive as the correct thing to do (plus it feels too easy to get into losing your commit message). Maybe we should have a "git rebase --amend", which does the obvious thing (acts like --continue, but lets you edit the message). It's not like you just did something totally different; the commit is still the replacement for D, it's just less the same.

	-Daniel
*This .sig left intentionally blank*