Re: [BUG?] Major performance issue with some commands on our repo's master branch

From: Jeff King <peff@peff.net>
Date: Jun 9, 2022, 15:05 UTC
Message-ID: <YqIMTYR2wM8iZCUN@coredump.intra.peff.net>
In-Reply-To: <87mtembcjl.fsf@gnu.org>

On Thu, Jun 09, 2022 at 07:51:36AM +0200, Tassilo Horn wrote:

Show 8 quoted lines

> > So probably setting diff.renamelimit correctly is not that bad a
> > solution.
> 
> Does your statement imply diff.renameLimit = 10000 is an incorrect
> setting?  The thing is that I mostly work with java codebases where
> every file rename implies a change in file contents, too.  A large
> renameLimit seems to help in correctly detecting renames/copies although
> I don't have empirical data but only gut feeling.

Well, for some definition of incorrect. :) You are telling Git to spend extra time computing renames, and then you were annoyed when it spent a long time computing renames. So in that sense it was not what you wanted.

It may be that you want different limits in different contexts, and the current config is not sufficient to express that.

-Peff