Re: cherry-pick is slow

Jeff King [off-list ref] 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:

quoted

quoted

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.