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

[Tassilo Horn <tsdh@gnu.org>]

Jeff King <peff@peff.net> writes:

Hi Jeff,

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