rename detection limit checking, cherry picking, and git am -3

[Mark Levedahl <mlevedahl@gmail.com>]

Linus' recent patch to invoke limiting on rename detection broke my 
ability to use cherry-picking on one project. This project has about 
4300 files on one branch (a), 2500 on a later branch (b), 226 commits in 
total between the two branches, and a convoluted history of how branch a 
morphed into branch b. About 50 files were renamed in the transition, 
and we need to migrate patches from the still maintained branch a onto 
the new branch b.

Prior to Linus' recent patch to limit rename detection (0024a549), 
cherry picking a patch from a to b, where the patch affected just one 
file, often took about 45 seconds on a 3 GHz pentium 4 with the CPU 
pegged at 100% for the duration. The cherry picking always succeeded and 
correctly followed renames, but was very slow.

Following Linus' patch, the cherry picking fails with a merge conflict 
(almost instantly), complaining the file has been deleted on b but 
modified on a, i.e., the rename detection does not work. I tried raising 
diff.renameLimit to 100000, that seems to have no effect whatsoever on 
cherry-pick (the process aborts with a conflict almost immediately).

Curiously, using "git format-patch x..y --stdout | git am -3" succeeds 
in this case, and runs in well less than a second. This performance 
seems unchanged by the rename detection limit patch.

So, the rename limit patch "broke" git for this usage, though one could 
reasonably argue the previous code was so slow as to be broken anyway.

The curious thing to me is the vast superiority of whatever 
git-format-patch|git-am -3 does, and I wonder if that isn't a 
fundementally better design for cherry picking than git-cherry-pick 
implements (it obviously is for this case).

Mark