Jeff King writes:
> ... 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.
Yeah, I think that is a very sensible thing to do.
--
To unsubscribe
Jeff King writes:
> I find that git.git is often a useful and easy thing to time to
> extrapolate to other projects. It's 1/10th-1/20th the size of the kernel
> (both in tree size and commit depth), which I do consider a "big
> project" (and I have a feeling is what Linus was talking about).
>
>
On Wed, Dec 03, 2014 at 08:40:47AM +1100, Bryan Turner wrote:
> On Tue, Dec 2, 2014 at 5:55 PM, Jeff King 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 project
On Tue, Dec 2, 2014 at 5:55 PM, Jeff King 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 (re
On Tue, Dec 02, 2014 at 09:57:07AM -0800, Junio C Hamano wrote:
> > 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 a
Jeff King writes:
> Interestingly, the rename behavior dates all the way back to:
>
> commit 753fd78458b6d7d0e65ce0ebe7b62e1bc55f3992
> Author: Linus Torvalds
> Date: Fri Jun 17 15:34:19 2005 -0700
>
> Use "-M" instead of "-C" for "git diff" and "git status"
>
> The "C" in "-C" ma
Jeff,
Thanks much for the detailed answer and analysis.
> 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'll have to pass on this. I'm absolutely not familia
On Sun, Nov 30, 2014 at 12:54:53PM +1100, Bryan Turner wrote:
> I'll let someone a little more intimately familiar with the internals
> of git status comment on why the documentation for that mentions
> copies.
I don't think there is a good reason. git-status has used renames since
mid-2005. The
Pol,
It's the same set of limitations. Git does not track renames or copies
as such. It uses heuristics to compute a similarity index and then
decide. All the tree stores for your copy is a file add, and that's
the status you're seeing. I don't think there is any way to turn on
aggressive copy det
Hi Bryan,
OK that explains the behavior of git diff, but what about git status?
The doc implies it should be able to detect copies in the index /
staging area since it has a "C" state.
- Pol
On Sun, Nov 30, 2014 at 10:03 AM, Bryan Turner wrote:
> Pol,
>
> By default, -C only finds copies when t
Pol,
By default, -C only finds copies when the source file was also
modified in the same commit. Since you did not modify hello.txt in the
same commit where you copied it to copied.txt, it will not be
considered.
If you pass -C -C (twice), or use --find-copies-harder, Git will
consider all files
Hi,
The documentation for git status at http://git-scm.com/docs/git-status
implies that it should be able to detect both renames and copies (with
the R and C states). The command git diff -C should do it as well.
However I can't get either to detect copies in this simple test case -
what is happe
12 matches
Mail list logo
