Jeff King <peff@xxxxxxxx> writes: > [let's keep this on-list so others can benefit from the discussion] > > On Tue, May 15, 2012 at 12:38:59PM +0400, Dmitry Risenberg wrote: > >> > It's probably detecting renames as part of the merge, which can be >> > expensive if the thing you are cherry-picking is far away from HEAD. You >> > can try setting the merge.renamelimit config variable to something small >> > (like 1; setting it to 0 means "no limit"). >> >> I set it to 1, but it didn't help at all - cherry-pick time is still >> about the same. > > OK, then my guess was probably wrong. You'll have to try profiling (if > you are on Linux, "perf record git cherry-pick ..."; perf report" is the > simplest way). Or if the repository is publicly available, I can do a > quick profile run. Perhaps the word "cherry-pick" invites an expectation that it must be faster than a full-tree merge, i.e. something like "format-patch | am -3", especially when the change introduced by the commit being cherry-picked touch only a handful of paths. Unfortunately, I do not think that the actual implementation of "cherry-pick" matches that expectation, as it is a full three-way merge. I am somewhat curious to see what the performance characteristics would be if the same commit is replayed using git format-patch -1 --stdout $commit | git apply --index --3way pipeline. Depending on the number of paths in the whole tree vs the number of paths the $commit touches, I wouldn't be surprised if it is faster. -- 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