Re: difflame improvements
- From
Edmundo Carmona Antoranz <eantoranz@gmail.com>
- Date
- Feb 19, 2017, 06:35 UTC
- Message-ID
- <CAOc6etY39Pi72U3ibtF94oh4xqzP4SB3VEj8QJOhX-GobTOTRA@mail.gmail.com>
- In-Reply-To
- <CAOc6etZxkspqafifjPTbRDoVBt0XuOLbhiuY9bFTD2Wjtxw-HQ@mail.gmail.com>
On Fri, Feb 17, 2017 at 1:01 AM, Edmundo Carmona Antoranz <eantoranz@gmail.com> wrote:
Show 22 quoted lines
> On Thu, Feb 16, 2017 at 11:17 PM, Jeff King <peff@peff.net> 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.