From: Jeff King <peff@peff•net>
To: Bryan Turner <bturner@atlassian•com>
Cc: Junio C Hamano <gitster@pobox•com>,
Pol Online <info@pol-online•net>, Git Users <git@vger•kernel.org>
Subject: Re: git status / git diff -C not detecting file copy
Date: Tue, 2 Dec 2014 16:50:13 -0500 [thread overview]
Message-ID: <20141202215013.GB25338@peff.net> (raw)
In-Reply-To: <CAGyf7-EHBqZn5LCTYuA+07GSNOF0vVdszL6oTUKwY1ETRDKEwA@mail.gmail.com>
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
next prev parent reply other threads:[~2014-12-02 21:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-30 0:35 git status / git diff -C not detecting file copy Pol Online
2014-11-30 1:03 ` Bryan Turner
2014-11-30 1:30 ` Pol Online
2014-11-30 1:54 ` Bryan Turner
2014-12-02 6:55 ` Jeff King
2014-12-02 14:15 ` Pol Online
2014-12-02 17:57 ` Junio C Hamano
2014-12-02 20:09 ` Jeff King
2014-12-03 16:01 ` Junio C Hamano
2014-12-02 21:40 ` Bryan Turner
2014-12-02 21:50 ` Jeff King [this message]
2014-12-03 16:03 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141202215013.GB25338@peff.net \
--to=peff@peff$(echo .)net \
--cc=bturner@atlassian$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=info@pol-online$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox