[RFC/PATCH 0/2] more patch-id speedups

[Jeff King <peff@peff.net>]

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