Re: [BUG] git-rebase fails when a commit message contains a diff

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 9, 2007, 02:37 UTC
Message-ID: <7v1wb0xhxq.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <Pine.LNX.4.64.0711090225110.4362@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 13 quoted lines

> 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.