copy vs rename detection: avoid unnecessary O(n*m) loops
commit644797119d7a3b7a043a51a9cccd8758f8451f91
authorLinus Torvalds <torvalds@linux-foundation.org>
Thu, 25 Oct 2007 18:20:56 +0000 (25 11:20 -0700)
committerJunio C Hamano <gitster@pobox.com>
Sat, 27 Oct 2007 06:18:06 +0000 (26 23:18 -0700)
treeed4e6fb50c33a3fe92028747244f7106b0a3a2fe
parent9fb88419ba85e641006c80db53620423f37f1c93
copy vs rename detection: avoid unnecessary O(n*m) loops

The core rename detection had some rather stupid code to check if a
pathname was used by a later modification or rename, which basically
walked the whole pathname space for all renames for each rename, in
order to tell whether it was a pure rename (no remaining users) or
should be considered a copy (other users of the source file remaining).

That's really silly, since we can just keep a count of users around, and
replace all those complex and expensive loops with just testing that
simple counter (but this all depends on the previous commit that shared
the diff_filespec data structure by using a separate reference count).

Note that the reference count is not the same as the rename count: they
behave otherwise rather similarly, but the reference count is tied to
the allocation (and decremented at de-allocation, so that when it turns
zero we can get rid of the memory), while the rename count is tied to
the renames and is decremented when we find a rename (so that when it
turns zero we know that it was a rename, not a copy).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff.c
diffcore-rename.c
diffcore.h