Jeff King <peff@xxxxxxxx> 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
