On Wed, Dec 03, 2014 at 08:40:47AM +1100, Bryan Turner wrote: > On Tue, Dec 2, 2014 at 5:55 PM, Jeff King <p...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
