Re: git-diff-tree inordinately (O(M*N)) slow on files with many changes
- From
- Davide Libenzi <davidel@xmailserver.org>
- Date
- Oct 16, 2006, 16:24 UTC
- Message-ID
- <Pine.LNX.4.64.0610160920250.7697@alien.or.mcafeemobile.com>
- In-Reply-To
- <Pine.LNX.4.64.0610160838200.3962@g5.osdl.org>
On Mon, 16 Oct 2006, Linus Torvalds wrote:
Show 15 quoted lines
> > Davide? I'm quoting the whole report, because I suspect you don't follow > the git lists, and this is all original libxdiff code. > > Jim: the annotation failure _may_ just be due to a "valid" diff change > (there is not always a unique correct answer for a diff, and so two > different diff algorithms can validly give two different answers, which > will also mean that git-annotate/blame would give different explanations). > > But it could certainly also be that you just broke the diffs entirely, so > I would like to wait for Davide to comment on your diff before Junio > should apply it. > > Others may be intimately familiar with the diff algorithms too, of course. > It just scares me personally ;)
The test is fine as is. Only really bad hash collisions can show O(M*N). Can I have the two sample files to test?
- Davide