difflame improvements

2017-03-05 Thread Edmundo Carmona Antoranz
Hi! Since my last post the biggest improvement is the ability to detect that the user has requested a "reverse" analysis. Under "normal" circumstances a user would ask difflame to get the diff from an ancestor (call "difflame treeish1 treeish2" so that merge-base of treeish1 treeish2 equals

Re: difflame improvements

2017-02-18 Thread Edmundo Carmona Antoranz
On Fri, Feb 17, 2017 at 1:01 AM, Edmundo Carmona Antoranz wrote: > On Thu, Feb 16, 2017 at 11:17 PM, Jeff King 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

Re: difflame improvements

2017-02-16 Thread Edmundo Carmona Antoranz
On Thu, Feb 16, 2017 at 11:17 PM, Jeff King 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

Re: difflame improvements

2017-02-16 Thread Jeff King
On Tue, Feb 14, 2017 at 11:19:05PM -0600, Edmundo Carmona Antoranz wrote: > I've been working on detecting revisions where a "real" deletion was > made and I think I advanced a lot in that front. I still have to work > on many scenarios (renamed files, for example... also performance) but > at

difflame improvements

2017-02-14 Thread Edmundo Carmona Antoranz
Hi! I've been working on detecting revisions where a "real" deletion was made and I think I advanced a lot in that front. I still have to work on many scenarios (renamed files, for example... also performance) but at least I'm using a few runs against git-scm history and the results are