On Fri, Feb 17, 2017 at 1:01 AM, Edmundo Carmona Antoranz <eantoranz@xxxxxxxxx> wrote: > On Thu, Feb 16, 2017 at 11:17 PM, Jeff King <peff@xxxxxxxx> wrote: > >> This isn't difflame's fault; that's what "git blame" tells you about >> that line. But since I already told difflame "v2.6.5..HEAD", it would >> probably make sense to similarly limit the blame to that range. That >> turns up a boundary commit for the line. Which is _also_ not helpful, >> but at least the tool is telling me that the line came from before >> v2.6.5, and I don't really need to care much about it. > > > I'm running my own tests on difflame and I have a theory about "when" > it breaks.... at least one of the cases when it breaks: > > Analysis for deleted lines is being driven by git blame --reverse. > What I have noticed is that it "breaks" when blame --reverse drives > the analysis into revisions where "treeish1" is not part of their > history (like, bringing analysis "to the sides" of treeish1 instead of > keeping analysis in revisions in the history of treeish2 that have > treeish1 as one of their ancestors.... which is definitely a valid > case for analysis, anyway). In this case, blame --reverse stops being > helpful. > At the cost of being slower, I just pushed to master the best results yet. The workaround I developed for the case I described on the previous mail ended up providing much better results overall so I ended up replacing the whole merge-analysis logic with it. Thanks for your kind help and comments, Peff. Let me know how it goes.