From: Junio C Hamano Date: Fri, 09 Nov 2007 02:37:37 GMT Subject: Re: [BUG] git-rebase fails when a commit message contains a diff Message-ID: <7v1wb0xhxq.fsf@gitster.siamese.dyndns.org> In-Reply-To: Johannes Schindelin 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.