From: Junio C Hamano Date: Mon, 12 Mar 2012 19:45:33 GMT Subject: Re: [PATCH 02/11] Introduce a performance test for git-rebase Message-ID: <7v399dsiw2.fsf@alter.siamese.dyndns.org> In-Reply-To: <87ipi9yaws.fsf@thomas.inf.ethz.ch> Thomas Rast 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.