Michael and I found a case where the "format-patch --cherry-pick A...B" command for a rebase took over 7 minutes to run with git v2.9.3. Yikes. Switching to v2.10 dropped that to a bit over 3 minutes (due to the kw/patch-ids-optim topic). Better, but not great. The culprit turned out to be merge commits; the patch-id code will happily diff a merge against its first parent, and ignore the rest. This _seems_ like a bad idea, but maybe there is something clever going on that I don't know about. I couldn't find anything useful in the history, and given that this code was adapted from rebase, my guess is that it was never really intended to handle merge commits in the first place (of course we weren't trying to rebase merge commits; but it has to generate patch-ids for everything that happened on "A" to compare against). Dropping the computation of the merge commits got it down to about 4 seconds. I also noticed that it was doing rename detection (which also seems like a bad idea). Disabling renames dropped another half second or so. This is marked as "RFC" because I don't feel entirely confident that I'm not missing some clever need for these options. But in both cases my gut feeling is that they are simply unintended effects that nobody ever noticed, because it would be very rare that they would affect the output. And that if they _did_ affect the output, they would probably be doing the wrong thing. -peff