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

[Jeff King <peff@peff.net>]

On Wed, Dec 03, 2014 at 08:40:47AM +1100, Bryan Turner wrote:

> On Tue, Dec 2, 2014 at 5:55 PM, Jeff King <peff@peff.net> wrote:
> >
> > So from these timings, I'd conclude that:
> >
> >   1. It's probably fine to turn on copies for "git status".
> >
> >   2. It's probably even OK to use "-C -C" for some projects. Even though
> >      22s looks scary there, that's only 11ms for git.git (remember,
> >      spread across 2000 commits). For linux.git, it's much, much worse.
> >      I killed my "-C -C" run after 10 minutes, and it had only gone
> >      through 1/20th of the commits. Extrapolating, you're looking at
> >      500ms or so added to a "git status" run.
> >
> >      So you'd almost certainly want this to be configurable.
> >
> > Does either of you want to try your hand at a patch? Just enabling
> > copies should be a one-liner. Making it configurable is more involved,
> > but should also be pretty straightforward.
> 
> I'm interested in taking a stab at a patch, but I'd like to confirm
> which way to go. Based on Junio's reply I'm not certain the simple
> patch could get accepted (assuming I do all the submission parts
> properly and the implementation itself passes review). Does that mean
> the only real option is the configurable patch?

I think this is the part where you get to use your judgement, and decide
what you think the maintainer will take. :)

Personally, I would probably go for the configurable version, as it is
not that much harder, and is a nicer end-point.

Junio gave an example elsewhere in which the config option value would
look like "-C -C". I'd consider trying to match diff.renames instead,
which takes false/true/copies for its three levels. It may make sense to
teach both places "copies-harder" or something similar, for
completeness.

-Peff