Jeff King <peff@xxxxxxxx> 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).
>
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html