Re: git status / git diff -C not detecting file copy
- From
Jeff King <peff@peff.net>
- Date
- Dec 2, 2014, 21:50 UTC
- Message-ID
- <20141202215013.GB25338@peff.net>
- In-Reply-To
- <CAGyf7-EHBqZn5LCTYuA+07GSNOF0vVdszL6oTUKwY1ETRDKEwA@mail.gmail.com>
On Wed, Dec 03, 2014 at 08:40:47AM +1100, Bryan Turner wrote:
Show 24 quoted lines
> 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