{"thread":{"id":"38437","subject":"Should copy/rename detection consider file overwrites?","startedAt":"2015-01-23T01:29:08Z","lastAt":"2015-01-23T22:37:15Z","messageCount":3,"participants":["Mike Hommey","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"255160","messageId":"20150123012908.GA8558@glandium.org","threadId":"38437","inReplyTo":null,"subject":"Should copy/rename detection consider file overwrites?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2015-01-23T01:29:08Z","receivedAt":"2015-01-23T01:29:08Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nWhile fooling around with copy/rename detection, I noticed that it\ndoesn't detect the case where you copy or rename a file on top of\nanother:\n\n$ git init\n$ (echo foo; echo bar) > foo\n$ git add foo\n$ git commit -m foo\n$ echo 0 > bar\n$ git add bar\n$ git commit -m bar\n$ git mv -f foo bar\n$ git commit -m foobar\n$ git log --oneline --reverse\n7dc2765 foo\nb0c837d bar\n88caeba foobar\n$ git blame -s -C -C bar\n88caebab 1) foo\n88caebab 2) bar\n\nI can see how this is not trivially representable in e.g. git diff-tree,\nbut shouldn't at least blame try to tell that those lines actually come\nfrom 7dc2765?\n\nMike\n"},{"id":"255167","messageId":"20150123110418.GA10028@peff.net","threadId":"38437","inReplyTo":"20150123012908.GA8558@glandium.org","subject":"Re: Should copy/rename detection consider file overwrites?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-01-23T11:04:19Z","receivedAt":"2015-01-23T11:04:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 23, 2015 at 10:29:08AM +0900, Mike Hommey wrote:\n\n> While fooling around with copy/rename detection, I noticed that it\n> doesn't detect the case where you copy or rename a file on top of\n> another:\n> \n> $ git init\n> $ (echo foo; echo bar) > foo\n\nIf I replace this with a longer input, like:\n\n  cp /usr/share/dict/words foo\n\n> $ git add foo\n> $ git commit -m foo\n> $ echo 0 > bar\n> $ git add bar\n> $ git commit -m bar\n> $ git mv -f foo bar\n> $ git commit -m foobar\n> $ git log --oneline --reverse\n> 7dc2765 foo\n> b0c837d bar\n> 88caeba foobar\n> $ git blame -s -C -C bar\n> 88caebab 1) foo\n> 88caebab 2) bar\n\nThen the blame shows me the initial \"foo\" commit. So I think it is\nmainly that your toy example is too small (I think we will do\nexact rename detection whatever the size is, but I expect we are getting\nhung up on the break detection between \"0\\n\" and \"foo\\nbar\\n\").\n\n> I can see how this is not trivially representable in e.g. git diff-tree,\n> but shouldn't at least blame try to tell that those lines actually come\n> from 7dc2765?\n\ndiff-tree can show this, too, but you need to turn on \"break detection\"\nwhich will notice that \"bar\" has essentially been rewritten (and then\nconsider its sides as candidates for rename detection). For example\n(with the longer input, as above):\n\n  $ git diff-tree --name-status -M HEAD\n  c6fe146b0c73adcbc4dbc2e58eb83af9007678bc\n  M       bar\n  D       foo\n\n  $ git diff-tree --name-status -M -B HEAD\n  c6fe146b0c73adcbc4dbc2e58eb83af9007678bc\n  R100    foo     bar\n\nPresumably if you set the break score low enough, your original example\nwould behave the same way, but I couldn't get it to work (I didn't look\nclosely, but I imagine it is just so tiny that we hit the internal\nlimits on how low you can set the score).\n\n-Peff\n"},{"id":"255234","messageId":"20150123223715.GB22303@glandium.org","threadId":"38437","inReplyTo":"20150123110418.GA10028@peff.net","subject":"Re: Should copy/rename detection consider file overwrites?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2015-01-23T22:37:15Z","receivedAt":"2015-01-23T22:37:15Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Jan 23, 2015 at 06:04:19AM -0500, Jeff King wrote:\n> On Fri, Jan 23, 2015 at 10:29:08AM +0900, Mike Hommey wrote:\n> \n> > While fooling around with copy/rename detection, I noticed that it\n> > doesn't detect the case where you copy or rename a file on top of\n> > another:\n> > \n> > $ git init\n> > $ (echo foo; echo bar) > foo\n> \n> If I replace this with a longer input, like:\n> \n>   cp /usr/share/dict/words foo\n> \n> > $ git add foo\n> > $ git commit -m foo\n> > $ echo 0 > bar\n> > $ git add bar\n> > $ git commit -m bar\n> > $ git mv -f foo bar\n> > $ git commit -m foobar\n> > $ git log --oneline --reverse\n> > 7dc2765 foo\n> > b0c837d bar\n> > 88caeba foobar\n> > $ git blame -s -C -C bar\n> > 88caebab 1) foo\n> > 88caebab 2) bar\n> \n> Then the blame shows me the initial \"foo\" commit. So I think it is\n> mainly that your toy example is too small (I think we will do\n> exact rename detection whatever the size is, but I expect we are getting\n> hung up on the break detection between \"0\\n\" and \"foo\\nbar\\n\").\n\nErr, I was afraid my testcase was too small. And that all boils down to\nthis:\n\n    <num> is optional but it is the lower bound on the number of\n    alphanumeric characters that Git must detect as moving/copying\n    between files for it to associate those lines with the parent\n    commit. And the default value is 40.\n\n> > I can see how this is not trivially representable in e.g. git diff-tree,\n> > but shouldn't at least blame try to tell that those lines actually come\n> > from 7dc2765?\n> \n> diff-tree can show this, too, but you need to turn on \"break detection\"\n> which will notice that \"bar\" has essentially been rewritten (and then\n> consider its sides as candidates for rename detection). For example\n> (with the longer input, as above):\n> \n>   $ git diff-tree --name-status -M HEAD\n>   c6fe146b0c73adcbc4dbc2e58eb83af9007678bc\n>   M       bar\n>   D       foo\n> \n>   $ git diff-tree --name-status -M -B HEAD\n>   c6fe146b0c73adcbc4dbc2e58eb83af9007678bc\n>   R100    foo     bar\n> \n> Presumably if you set the break score low enough, your original example\n> would behave the same way, but I couldn't get it to work (I didn't look\n> closely, but I imagine it is just so tiny that we hit the internal\n> limits on how low you can set the score).o\n\nOh. Good to know, thanks.\n\nMike\n"}]}