Re: [PATCH 1/2] git-commit: Disallow unchanged tree in non-merge mode

Linus Torvalds [off-list ref] writes:

Yeah, we should probably:
 - default to something larger but still reasonably sane (ie not 100, but 
   perhaps 1000)
 - special-case the "identical rename", and have a higher limit for that 
   (we already handle the identicals as a separate pass before we even 
   start doing the similarity analysis - and it's the similarity analysis 
   that can be the really expensive part)

There's really no point in trying to do rename analysis for tons and tons 
of files - even if we find perfect renames, the diff is going to be 
unreadable by a human, so realistically nobody is ever going to care! A 
machine won't care whether it was done as a create/delete or a rename, and 
a human won't be bothered to read about thousands of renames, so we're 
just wasting time trying to make it prettier.

So quite arguably, the only case we really care about for renames is when 
the numbers are small enough to be human-readable.

I agree with that.  At the same time we might want to revisit
the earlier "build a full matrix and pick the best ones"
approach commit 5c97558c9a813a0a775c438a79cfc438def00c22 (Detect
renames in diff family) introduced.

A tangent.

I've been thinking about updating the diffcore-rename for some
time to give bonus points to a filepair whose neighbors are
detected to be renames.  E.g. if you have this pair of preimage
and postimage:

	(preimage)		(postimage)

	arch/i386/foo.c		arch/x86/foo-32.c
	arch/i386/bar.c		arch/x86/bar-32.c
	arch/i386/baz.c		arch/x86/baz-32.c

and if foo.c and bar.c are found to be very similar to foo-32.c
and bar-32.c while baz.c and baz-32.c are not that much, we may
want to take hints from the movement of neighbouring files and
boost the similarity score between baz.c and baz-32.c pair.

It would be a quite an interesting coding challenge for anybody
who wants to get his hands dirty.  Would this be worth it in
practice?  I dunno.