On Thu, 8 Nov 2007, 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 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*
