Re: slow git-cherry-pick.

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

 



On Sunday 24 of November 2013 19:47:10 Duy Nguyen wrote:
> On Sun, Nov 24, 2013 at 5:45 PM, Paweł Sikora <pawel.sikora@xxxxxxxx> wrote:
> > i've recently reinstalled a fresh system (fc20-beta) on my workstation
> > and observing a big slowdown on git cherry-pick operation (git-1.8.4.2-1).
> > the previous centos installation with an old git version works faster
> > (few seconds per cherry pick). now the same operation takes >1 min.
> 
> What is the git version before the reinstallation?

git-1.7.11.3-1.el5.rf.

i've checked this version on another machine with centos-5.$latest
and it does similar amout of stat/read operation quickly (~6s).
this "fast" centos-5 machine has /home on raid-0 (2x500GB) while
my "slow (>1min)" workstation has /home on linear lvm (250G+1T).

so, i suppose that my "slow" working copy crosses disks boundary
or spread over 1TB drive and the random git i/o impacts performance.

the question still remains - does the git need to scan whole checkout
during picking well defined set of files?

> Do you cherry-pick on one commit or a commit range?

single commit.

-- 
gpg key fingerprint = 60B4 9886 AD53 EB3E 88BB  1EB5 C52E D01B 683B 9411
--
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]