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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 2, 2014, 17:57 UTC
Message-ID: <xmqqvblukk98.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20141202065550.GB1948@peff.net>

Jeff King <peff@peff.net> writes:

Show 16 quoted lines

> Interestingly, the rename behavior dates all the way back to:
>
>   commit 753fd78458b6d7d0e65ce0ebe7b62e1bc55f3992
>   Author: Linus Torvalds <torvalds@ppc970.osdl.org>
>   Date:   Fri Jun 17 15:34:19 2005 -0700
>
>   Use "-M" instead of "-C" for "git diff" and "git status"
>   
>   The "C" in "-C" may stand for "Cool", but it's also pretty slow, since
>   right now it leaves all unmodified files to be tested even if there are
>   no new files at all.  That just ends up being unacceptably slow for big
>   projects, especially if it's not all in the cache.
> ...
> To get a rough sense of how much effort is entailed in the various
> options, here are "git log --raw" timings for git.git (all timings are
> warm cache, best-of-five, wall clock time):

The rationale of the change talks about "big projects" and your analysis and argument to advocate reversion of that change is based on "git.git"? What is going on here?

Also our history is fairly unusual in that we do not have a lot of renames (there was one large "s|builtin-|builtin/|" rename event, but that is about it), which may not be a good example to base such a design decision on.

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