On Fri, Jan 23, 2015 at 06:04:19AM -0500, Jeff King wrote:
> On Fri, Jan 23, 2015 at 10:29:08AM +0900, Mike Hommey wrote:
>
> > While fooling around with copy/rename detection, I noticed that it
> > doesn't detect the case where you copy or rename a file on top of
> > another:
> >
> > $ git init
> > $ (echo foo; echo bar) > foo
>
> If I replace this with a longer input, like:
>
> cp /usr/share/dict/words foo
>
> > $ git add foo
> > $ git commit -m foo
> > $ echo 0 > bar
> > $ git add bar
> > $ git commit -m bar
> > $ git mv -f foo bar
> > $ git commit -m foobar
> > $ git log --oneline --reverse
> > 7dc2765 foo
> > b0c837d bar
> > 88caeba foobar
> > $ git blame -s -C -C bar
> > 88caebab 1) foo
> > 88caebab 2) bar
>
> Then the blame shows me the initial "foo" commit. So I think it is
> mainly that your toy example is too small (I think we will do
> exact rename detection whatever the size is, but I expect we are getting
> hung up on the break detection between "0\n" and "foo\nbar\n").
Err, I was afraid my testcase was too small. And that all boils down to
this:
<num> is optional but it is the lower bound on the number of
alphanumeric characters that Git must detect as moving/copying
between files for it to associate those lines with the parent
commit. And the default value is 40.
> > I can see how this is not trivially representable in e.g. git diff-tree,
> > but shouldn't at least blame try to tell that those lines actually come
> > from 7dc2765?
>
> diff-tree can show this, too, but you need to turn on "break detection"
> which will notice that "bar" has essentially been rewritten (and then
> consider its sides as candidates for rename detection). For example
> (with the longer input, as above):
>
> $ git diff-tree --name-status -M HEAD
> c6fe146b0c73adcbc4dbc2e58eb83af9007678bc
> M bar
> D foo
>
> $ git diff-tree --name-status -M -B HEAD
> c6fe146b0c73adcbc4dbc2e58eb83af9007678bc
> R100 foo bar
>
> Presumably if you set the break score low enough, your original example
> would behave the same way, but I couldn't get it to work (I didn't look
> closely, but I imagine it is just so tiny that we hit the internal
> limits on how low you can set the score).o
Oh. Good to know, thanks.
Mike
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html