summaryrefslogtreecommitdiff
path: root/git-merge-octopus.sh
diff options
context:
space:
mode:
authorLibravatar Linus Torvalds <torvalds@linux-foundation.org>2007-10-25 11:20:56 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2007-10-26 23:18:06 -0700
commit644797119d7a3b7a043a51a9cccd8758f8451f91 (patch)
treeed4e6fb50c33a3fe92028747244f7106b0a3a2fe /git-merge-octopus.sh
parentRef-count the filespecs used by diffcore (diff)
downloadtgif-644797119d7a3b7a043a51a9cccd8758f8451f91.tar.xz
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>
Diffstat (limited to 'git-merge-octopus.sh')
0 files changed, 0 insertions, 0 deletions