Re: cherry-pick is slow

From: Junio C Hamano <gitster@pobox.com>
Date: May 15, 2012, 20:32 UTC
Message-ID: <7v1umldw3i.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120515132451.GA25378@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 16 quoted lines

> [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.