Re: cherry-pick is slow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2012/5/13 Junio C Hamano <gitster-vger@xxxxxxxxx>:
> On Sat, May 12, 2012 at 3:39 PM, Dmitry Risenberg
> <dmitry.risenberg@xxxxxxxxx> wrote:
>>
>> Hello.
>>
>> I have a very big git repository (the .git directory is about 5.3 Gb),
>> which is a copy of an svn repository fetched via git-svn. In fact
>> there are a few repositories ("working copies") that share the same
>> .git directory (via symlinks), in which I have different svn branches
>> checked out. Now I want to merge a commit from one svn branch to
>> another via git cherry-pick. The commit contains diff in only one
>> file. So I do
>>
>> git cherry-pick <commit>
>>
>> And the operation takes tens of seconds to finish. In "top" output I
>> see that git process uses almost no CPU, but has hundreds of page
>> faults, so I assume that it is reading a lot of files from disk.
>
> Wild guess: poorly (or worse yet, never) packed repository?

You were absolutely right.
I set "gc.auto = 0" during the initial checkout of svn and forgot to
turn it on afterwards. After running "git gc", my repo became two
times smaller, and git operations are now running much faster.

However, cherry-picking is still not as fast as I expected it to be -
cherry-picking a single-file commit takes about 14-15 seconds, fully
using one CPU core. Anything else I can improve?

-- 
Dmitry Risenberg
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]