git/diffcore-rename.c, branch v1.2.2

short circuit out of a few places where we would allocate zero bytes

2005-12-26T16:59:21Z

dietlibc versions of malloc, calloc and realloc all return NULL if they're told to allocate 0 bytes, causes the x* wrappers to die(). There are several more places where these calls could end up asking for 0 bytes, too... Maybe simply not die()-ing in the x* wrappers if 0/NULL is returned when the requested size is zero is a safer and easier way to go. Signed-off-by: Eric Wong Signed-off-by: Junio C Hamano

rename detection with -M100 means "exact renames only".

2005-11-21T20:21:24Z

When the user is interested in pure renames, there is no point doing the similarity scores. This changes the score argument parsing to special case -M100 (otherwise, it is a precision scaled value 0 <= v < 1 and would mean 0.1, not 1.0 --- if you do mean 0.1, you can say -M1), and optimizes the diffcore_rename transformation to only look at pure renames in that case. Signed-off-by: Junio C Hamano

diff: make default rename detection limit configurable.

2005-11-15T23:08:27Z

A while ago, a rename-detection limit logic was implemented as a response to this thread: http://marc.theaimsgroup.com/?l=git&m=112413080630175 where gitweb was found to be using a lot of time and memory to detect renames on huge commits. git-diff family takes -l flag, and if the number of paths that are rename destination candidates (i.e. new paths with -M, or modified paths with -C) are larger than that number, skips rename/copy detection even when -M or -C is specified on the command line. This commit makes the rename detection limit easier to use. You can have: [diff] renamelimit = 30 in your .git/config file to specify the default rename detection limit. You can override this from the command line; giving 0 means 'unlimited': git diff -M -l0 We might want to change the default behaviour, when you do not have the configuration, to limit it to say 20 paths or so. This would also help the diffstat generation after a big 'git pull'. Signed-off-by: Junio C Hamano

Diff: -l to limit rename/copy detection.

2005-09-25T06:50:44Z

When many paths are modified, rename detection takes a lot of time. The new option -l can be used to disable rename detection when more than paths are possibly created as renames. Signed-off-by: Junio C Hamano

Plug diff leaks.

2005-09-15T23:13:43Z

It is a bit embarrassing that it took this long for a fix since the problem was first reported on Aug 13th. Message-ID: <87y876gl1r.wl@mail2.atmark-techno.com> From: Yasushi SHOJI Newsgroups: gmane.comp.version-control.git Subject: [patch] possible memory leak in diff.c::diff_free_filepair() Date: Sat, 13 Aug 2005 19:58:56 +0900 This time I used valgrind to make sure that it does not overeagerly discard memory that is still being used. Signed-off-by: Junio C Hamano

Fix copy marking from diffcore-rename.

2005-09-10T19:42:32Z

When (A,B) ==> (B,C) rename-copy was detected, we incorrectly said that C was created by copying B. This is because we only check if the path of rename/copy source still exists in the resulting tree to see if the file is renamed out of existence. In this case, the new B is created by copying or renaming A, so the original B is lost and we should say C is a rename of B not a copy of B. Signed-off-by: Junio C Hamano

[PATCH] Use enhanced diff_delta() in the similarity estimator.

2005-06-29T00:13:32Z

The diff_delta() interface was extended to reject generating too big a delta while we were working on the packed GIT archive format. Take advantage of that when generating delta in the similarity estimator used in diffcore-rename.c Signed-off-by: Junio C Hamano Signed-off-by: Linus Torvalds

Add a "max_size" parameter to diff_delta()

2005-06-26T02:30:20Z

Anything that generates a delta to see if two objects are close usually isn't interested in the delta ends up being bigger than some specified size, and this allows us to stop delta generation early when that happens.

[PATCH] Fix rename/copy when dealing with temporarily broken pairs.

2005-06-13T03:40:19Z

When rename/copy uses a file that was broken by diffcore-break as the source, and the broken filepair gets merged back later, the output was mislabeled as a rename. In this case, the source file ends up staying in the output, so we should label it as a copy instead. Signed-off-by: Junio C Hamano Signed-off-by: Linus Torvalds

[PATCH] diff: Clean up diff_scoreopt_parse().

2005-06-03T18:23:03Z

This cleans up diff_scoreopt_parse() function that is used to parse the fractional notation -B, -C and -M option takes. The callers are modified to check for errors and complain. Earlier they silently ignored malformed input and falled back on the default. Signed-off-by: Junio C Hamano Signed-off-by: Linus Torvalds