Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
