On 2007.11.08 18:37:37 -0800, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
