RE: cherry-pick very slow on big repository
- Date: Fri, 10 Nov 2017 17:04:40 +0000
- From: Kevin Willford <kewillf@xxxxxxxxxxxxx>
- Subject: RE: cherry-pick very slow on big repository
Since this is happening during a merge, you might need to use merge.renameLimit
or the merge strategy option of -Xno-renames. Although the code does fallback
to use the diff.renameLimit but there is still a lot that is done before even checking
the rename limit so I would first try getting renames turned off.
> -----Original Message-----
> From: git-owner@xxxxxxxxxxxxxxx [mailto:git-owner@xxxxxxxxxxxxxxx] On Behalf
> Of Peter Krefting
> Sent: Friday, November 10, 2017 7:05 AM
> To: Derrick Stolee <stolee@xxxxxxxxx>
> Cc: Jeff King <peff@xxxxxxxx>; Git Mailing List <git@xxxxxxxxxxxxxxx>
> Subject: Re: cherry-pick very slow on big repository
> Derrick Stolee:
> > 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).
> Yes, a couple of directories with a lot of template files have been
> renamed (and some removed, some added) between the current development
> branch and this old maintenance branch. I get the "Performing inexact
> rename detection" a lot when merging changes in the other direction.
> However, none of them applies to these particular commits, which only
> touches files that are in the exact same location on both branches.
> > You can remove this rename detection by running your cherry-pick
> > with `git -c diff.renameLimit=1 cherry-pick ...`
> That didn't work, actually it failed to finish with this setting in
> effect, it hangs in such a way that I can't stop it with Ctrl+C
> (neither when running from the command line, nor when running inside
> gdb). It didn't finish in the 20 minutes I gave it.
> I also tried with diff.renames=false, which also seemed to fail.
> \\// Peter -