The merge from hell...

Ok,
 I've been holding off on having octopus merges in the kernel tree, but I 
just merged an ACPI update that had used one of them, and I didn't really 
see any real reason not to take it.

That octopus commit has got _twelve_ parents.

It's commit 9fdb62af92c741addbea15545f214a6e89460865, and passing it to git-diff-tree with the "--cc" option seems to do the largely the right thing (although arguably, since one of the parents always matches the end result in all the files, it shouldn't have shown anything at all, so I think it could do with some tweaking).

git-diff-tree takes almost three seconds to get its result, though.

However, if git-diff-tree is a bit slow, then gitk gets _really_ upset when you click on it. Apparently the colorized multi-way diff just breaks down into some O(2**n) hell.

I'm sure it's making progress, it's just very slow, and gitk is essentially unusable on that commit (gitk also gets visually confused by the fact that it forces a wider set of history than gitk expects, since it can't prune it down with the arrow notation).

[ Ahh. gitk just came back. After a _loong_ time thinking, and having run
  out of different colors, but looking otherwise fairly nice ;]

So think of it as a correctness/scalability test.

I haven't tried qgit or gitview on it, but am cc'ing Marco and Aneesh in case they want to hone their octopus skills on it.

Btw, I think you're better off parsing the "git-diff-tree --cc" output than doing it yourself like gitk does, now that core git has support for things like that.

			Linus