From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Sun, 11 Nov 2007 22:31:34 GMT
Subject: Re: [BUG] git-rebase fails when a commit message contains a diff
Message-ID: <20071111223134.GA12699@atjola.homenet>
In-Reply-To: <7v1wb0xhxq.fsf@gitster.siamese.dyndns.org>

On 2007.11.08 18:37:37 -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Thu, 8 Nov 2007, Junio C Hamano wrote:
> >
> >> I wonder if this is a sensible thing to do, regardless of the issue of 
> >> commit log message that contains anything.
> >> 
> >> The patch replaces git-rebase with git-rebase--interactive.  The only 
> >> difference from the existing "git-rebase -i" is if the command is called 
> >> without "-i" the initial "here is the to-do list. please rearrange the 
> >> lines, modify 'pick' to 'edit' or whatever as appropriate" step is done 
> >> without letting the user edit the list.
> >
> > Hmm.  I don't know, really.  I had the impression that the "git 
> > format-patch | git am" pipeline would be faster.
> 
> Heh, I did not read rebase--interactive carefully enough.
> 
> Unless told to use merge with "rebase -m", rebase replays the
> change by extracting and applying patches, and speed comparison
> was about that vs merge based replaying; I thought make_patch
> was done in order to avoid using cherry-pick (which is based on
> merge-recursive) and doing patch application with three-way
> fallback.  Apparently that is not what "interactive" does.
> 
> Perhaps pick_one () could be taught to perform the 3-way
> fallback dance git-am plays correctly.  The patch I sent to make
> git-rebase--interactive take over git-rebase would then become
> quite reasonable, I would think.

Note that git-rebase--interactive also doesn't really support the
--strategy parameter which git-rebase handles using git-merge-* instead
of git-am. Only merge commits during a -i -p run actually apply the
strategy.

Björn