Jakub Narebski <jnareb@xxxxxxxxx> wrote: > Shawn O. Pearce wrote: > > > (Regarding the performance, cherry-picking 55 patches is > > slow, especially when many of them would apply trivially with > > git-diff|git-apply --index. Be nice to improve that in 1.5.4.) > > Perhaps in the future you would be able to use -i/--interactive mode > in merge driven git-rebase (git rebase --merge -i <base>), which I think > should be faster. Heh. You're talking to someone who actually knows what he is talking about here, and was actually involved in some of these tools... Let me fill the reader in on what's really happening... `git-rebase` (non -i, non -m) uses `format-patch|am` to apply the changes of each commit it is rebasing. This is insanely fast as builtin diff and apply routines are quite efficient. It sometimes fails due to patches not applying cleanly. In those cases you have to either hand edit the patch, apply and continue the rebase, or abort the rebase and restart with the -m flag so it uses a full three-way file merge. `git-rebase -m` (aka --merge) uses git-merge-recursive to apply the changes of each commit it is rebasing. (That's the merge part!) However merge-recursive usually takes longer to run then the above `format-patch|am` pipeline, and that is why -m is not the default. But it does handle cases `format-patch|am` cannot do automatically. For quite a long time now both `git-revert` and `git-cherry-pick` (which are actually the same program!) have also been using git-merge-recursive as their implementation to revert or apply the commit's change. This allows them to perform changes that also involve renames, as well as to apply some changes that might fail as a patch but succeed when done as a three-way file merge. So really `revert`, `cherry-pick`, `rebase -m` (and also `am -3` as it also uses merge-recursive) are all the same underlying implementation. The major differences between them is what they do *after* the changes have been applied, and which direction the change goes (e.g. revert undoes the change). Now the new `git-rebase -i` is really just a complicated loop around `cherry-pick`. Really. Go look at the code, it never calls anything except cherry-pick. So `rebase -i` is actually `rebase --merge -i`. That's why its sluggish. Why is merge-recursive sluggish? It does rename detection. It does full three-way file merges, rather than just applying a patch. It also tries to do a three-way read-tree before doing file level merges. git-apply does none of these things, and is faster because of it. So that future you speak of above is today. Its also not faster, its slower. Faster would be to do something like `format-patch|am -3` so that merge-recursive is only invoked if git-apply was unable to apply the patch automatically. Except we'd want to save the original tree data so we can do proper rename detection when merge-recursive is fired up. -- Shawn. - 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
