Re: cherry-pick very slow on big repository

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

 



On 11/10/2017 7:37 AM, Peter Krefting wrote:
Jeff King:

Can you get a backtrace? I'd do something like:

Seems that it spends most time in diffcore_count_changes(), that is where it hits whenever I hit Ctrl+C (various line numbers 199-207 in diffcore-delta.c; this is on the v2.15.0 tag).

(gdb) bt
#0  diffcore_count_changes (src=src@entry=0x55555db99970,
    dst=dst@entry=0x55555d6a4810,
    src_count_p=src_count_p@entry=0x55555db99998,
    dst_count_p=dst_count_p@entry=0x55555d6a4838,
    src_copied=src_copied@entry=0x7fffffffd3e0,
    literal_added=literal_added@entry=0x7fffffffd3f0)
    at diffcore-delta.c:203
#1  0x00005555556dee1a in estimate_similarity (minimum_score=30000,
    dst=0x55555d6a4810, src=0x55555db99970) at diffcore-rename.c:193
#2  diffcore_rename (options=options@entry=0x7fffffffd4f0)
    at diffcore-rename.c:560
#3  0x0000555555623d83 in diffcore_std (
    options=options@entry=0x7fffffffd4f0) at diff.c:5846
...

Git is spending time detecting renames, which implies you probably renamed a folder or added and deleted a large number of files. This rename detection is quadratic (# adds times # deletes).

You can remove this rename detection by running your cherry-pick with `git -c diff.renameLimit=1 cherry-pick ...`

See https://git-scm.com/docs/diff-config#diff-config-diffrenameLimit

Thanks,
-Stolee



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

  Powered by Linux