{"thread":{"id":"31617","subject":"git diff-tree -r -C output inexact sometimes","startedAt":"2012-09-21T03:20:31Z","lastAt":"2012-09-21T06:03:39Z","messageCount":2,"participants":["Cristian Tibirna","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"199637","messageId":"2789023.yr3ihcVOhq@leto","threadId":"31617","inReplyTo":null,"subject":"git diff-tree -r -C output inexact sometimes","fromName":"Cristian Tibirna","fromEmail":"tibirna@kde.org","sentAt":"2012-09-21T03:20:31Z","receivedAt":"2012-09-21T03:20:31Z","isPatch":false,"sender":{"key":"tibirna@kde.org","avatar":null},"body":"Hello\n\nA colleague of mine discovered an inconsistency in the functioning of \n\ngit diff-tree -r -C\n\nin specific conditions. As tenuous as these conditions might seem (once you \nrun the script in attachment and analyse its output), please rest assured that \nit comes from a real-life case.\n\nRunning the script in attachment produces a git repository in which were \noperated a large number of file renames, in which many of the renamed files \n(in this particular case all) have the same content but different names.\n\nThe commit data from the renaming operation (last commit in the script-\ngenerated history) is inexactly rendered by the command \n\ngit diff-tree -r -C master\n\nThe logical result is correctly produced by the more restricted command\n\ngit diff-tree -r -M master\n\nIMO for this particular last commit both the above commands should return the \nsame result.\n\nNote that reducing i or j in the generator script attached below makes the bug \ndissapear.\n\nThanks a lot for your attention.\n\n-- \nCristian Tibirna\nKDE developer .. tibirna@kde.org .. http://www.kde.org\n"},{"id":"199645","messageId":"20120921060339.GA9844@sigill.intra.peff.net","threadId":"31617","inReplyTo":"2789023.yr3ihcVOhq@leto","subject":"Re: git diff-tree -r -C output inexact sometimes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-21T06:03:39Z","receivedAt":"2012-09-21T06:03:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 20, 2012 at 11:20:31PM -0400, Cristian Tibirna wrote:\n\n> Running the script in attachment produces a git repository in which were \n> operated a large number of file renames, in which many of the renamed files \n> (in this particular case all) have the same content but different names.\n> \n> The commit data from the renaming operation (last commit in the script-\n> generated history) is inexactly rendered by the command \n> \n> git diff-tree -r -C master\n> \n> The logical result is correctly produced by the more restricted command\n> \n> git diff-tree -r -M master\n> \n> IMO for this particular last commit both the above commands should return the \n> same result.\n\nInteresting. I get the same results from both commands. But I did have\nto munge your script, as my \"rename\" command does not seem to work like\nthe one you expect in your script. So I may have misinterpreted the\nintent of it.\n\nHowever, I would not be surprised if one could conduct a situation in\nwhich \"-C\" and \"-M\" produced different results. Since the content of all\nthe files is the same, git has to make a guess about which files match\nup based on their filenames. The current heuristic is very stupid and\njust tries to match basenames (e.g., moving \"foo/Makefile\" to\n\"bar/Makefile\" is a better match than moving the same content to\n\"bar/foo.c\"). But in this case, the basenames don't match at all.\n\nBy using \"-C\", we will typically have more rename sources available, and\nwe may therefore process the possible pairs in a different order. Since\nour name heuristic is largely useless, our results depend on that order.\n\nI think the real solution is to improve the name heuristic. Something\nlike an edit distance would make more sense (though I think it is not as\nsimple as an edit distance across the whole pathname, as moving a\nbasename across directories should probably be preferred to changing the\nfilename inside a directory).\n\nLargely I think nobody has cared much because this only comes up when\nyou move multiple identical files. Quite often there is a minor\ndifference even between very similar files, and that is enough to come\nup with sane results.\n\n-Peff\n"}]}