Re: slow git-cherry-pick.
- From
- Paweł Sikora <pawel.sikora@agmk.net>
- Date
- Nov 24, 2013, 19:17 UTC
- Message-ID
- <32998962.pucYdvRloz@localhost.localdomain>
- In-Reply-To
- <CACsJy8CAAov1nSGPx79U+md4xROsCydidHPcipOb_sdFwNdSkA@mail.gmail.com>
On Sunday 24 of November 2013 19:47:10 Duy Nguyen wrote:
Show 7 quoted lines
> On Sun, Nov 24, 2013 at 5:45 PM, Paweł Sikora <pawel.sikora@agmk.net> 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