Thomas Rast <trast@xxxxxxxxxxx> writes: > However, it's pretty obvious that 'rebase -f' is slow compared to > 'rebase -m'. So slow in fact that the user would be better off running > an *interactive* rebase. The mention of "-f" got me off track, but does "-m" avoid creating new commits when it does not have to? A side effect "-f" has is to replay _all_ the commits, if I recall correctly. > This comes from the i18n support added in adc3b2b27..a9f578685, and from > 43c2325 (am: use get_author_ident_from_commit instead of mailinfo when > rebasing, 2010-06-16). > Now I'm not really keen on hacking on git-am until it gets back its > performance, as for most uses it's probably still fast enough. But I > think one important question is: can we get rid of the > git-format-patch|git-am mode of git-rebase, which has historically been > a source of pain (see, e.g., the aforementioned 43c2325)? In the longer term, the right way forward is to try doing less in the patch mode in rebase. For example, the command could make the list of commits to be replayed exactly the same way as it does for flattening cherry-pick rebase, and instead of running "am", run "format-patch --stdout | apply --3way --whitespace=fix --index" and commit the result using "commit -C". That way it can depend on "commit -C" and does not have to worry about stupid things like 43c2325. -- 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