It does this only when doing diffs or annotations, not when retrieving logs.
So the log will not show the original filename of a copy then, only for a "resurrection"? Can this be fixed by using the resurrection method (whatever it is) instead of regular cp to copy the file? I mean, you should be able to "resurrect" a file regardless of whether it was actually deleted in a later commit or not, and since you can "resurrect" it to a new filename, that would serve as a copy operation.
No, it is not a performance problem because everything internally is hashed, i.e. it's not comparing large amounts of texts, it's comparing hashes mostly.
Ok, now I'm confused. You previously implied that I could make local changes (up to 50%) before commit and it would still be recognized as a copy. That would mean that it has to compare more than just a hash.
Also, I'm not entirely comfortable with the though that the history of an already committed file might spontanously change later.
It doesn't. There are such things as regression tests, development and quality assurance on git is *very* active.
You said previously that the "usual" way to fix an incorrect guess was to change the logic in git, and that this had indeed happened. How does regression tests help if people are deliberately changing the behaviour?