Do linear-time/space rename logic for exact renames
commit9027f53cb5051bf83a0254e7f8aeb5d1a206de0b
authorLinus Torvalds <torvalds@linux-foundation.org>
Thu, 25 Oct 2007 18:23:26 +0000 (25 11:23 -0700)
committerJunio C Hamano <gitster@pobox.com>
Sat, 27 Oct 2007 06:18:06 +0000 (26 23:18 -0700)
tree3ee3d48a47f89d7c41c5a9e4430f0db6507f4d9e
parent644797119d7a3b7a043a51a9cccd8758f8451f91
Do linear-time/space rename logic for exact renames

This implements a smarter rename detector for exact renames, which
rather than doing a pairwise comparison (time O(m*n)) will just hash the
files into a hash-table (size O(n+m)), and only do pairwise comparisons
to renames that have the same hash (time O(n+m) except for unrealistic
hash collissions, which we just cull aggressively).

Admittedly the exact rename case is not nearly as interesting as the
generic case, but it's an important case none-the-less. A similar general
approach should work for the generic case too, but even then you do need
to handle the exact renames/copies separately (to avoid the inevitable
added cost factor that comes from the _size_ of the file), so this is
worth doing.

In the expectation that we will indeed do the same hashing trick for the
general rename case, this code uses a generic hash-table implementation
that can be used for other things too.  In fact, we might be able to
consolidate some of our existing hash tables with the new generic code
in hash.[ch].

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile
diffcore-rename.c
hash.c [new file with mode: 0644]
hash.h [new file with mode: 0644]