Re: [BUG] git-rebase fails when a commit message contains a diff
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Nov 9, 2007, 14:19 UTC
- Message-ID
- <Pine.LNX.4.64.0711091418510.4362@racer.site>
- In-Reply-To
- <7v1wb0xhxq.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 8 Nov 2007, Junio C Hamano wrote:
Show 29 quoted lines
> 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.
I have a different idea: How about changing cherry-pick to try a simple patch first? If that fails, we can always go back to merge-recursive (or merge-nu once that is ready).
Ciao, Dscho