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

From: Tassilo Horn <tsdh@gnu.org>
Date: Jun 9, 2022, 05:51 UTC
Message-ID: <87mtembcjl.fsf@gnu.org>
In-Reply-To: <YqEyh5opAaJxph2+@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Hi Jeff,

Show 11 quoted lines

>> Still maybe someone might want to have a look at the "git show" issue
>> to double-check if the performance burden in this specific case (no
>> diff should be generated) is warranted.  But at least I can work
>> again with no coffee-break long pauses, so I'm all satisfied. :-)
>
> I suspect the issue may be quite subtle. Even you asked for
> "--no-patch", the underlying diff may still be used for other things.
> For example, simplifying away TREESAME commits. I.e., ones which did
> not change anything from their parents after applying path
> restrictions, diff-filters, etc. There may be other cases, too (e.g.,
> --follow).

I see. In the end, my issue was solved by my git porcelain switching to a "git log" incarnation instead of "git show". When I "git show" manually, it's no big deal if it takes some time for merge commits.

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

Bye, Tassilo