Re: git status / git diff -C not detecting file copy

Jeff King [off-list ref] writes:

I find that git.git is often a useful and easy thing to time to
extrapolate to other projects. It's 1/10th-1/20th the size of the kernel
(both in tree size and commit depth), which I do consider a "big
project" (and I have a feeling is what Linus was talking about).

Of course, performance numbers do not always scale linearly with repo
size.
...
What does impact it is the _size_ of each commit. If you quite
frequently add a new file while touching tens of thousands of other
files, then the performance will be a lot more noticeable. And both
git.git and linux.git are probably better than some other projects about
having small commits.

Yes, the number of paths touched per-commit in git.git may not be
typical.  If it is unusually lower, that would skew the result, as
the cost of rename detection is proportional to it, and the cost of
-C -C is that number times the number of total paths in the project.

Still, though. I stand by my earlier conclusions. Even with commits ten
times as large as the kernel's, you are talking about 3ms added to a
"status" run (and again, only when you hit such a gigantic commit _and_
it has an 'A' file).

quoted

It is a fine idea to make this configurable ("status.renames = -C"
or something, perhaps?), though.

I think it would be OK to move to "-C" as a default, but I agree it is
nicer if it is configurable, as it gives a safety hatch for people in
pathological repos to drop back to the old behavior (or even turn off
renames altogether).

Yeah I am OK with that, too.