2005-05-21 11:39:09 +02:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2005 Junio C Hamano
|
|
|
|
*/
|
|
|
|
#include "cache.h"
|
|
|
|
#include "diff.h"
|
|
|
|
#include "diffcore.h"
|
2007-10-25 20:23:26 +02:00
|
|
|
#include "hash.h"
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2005-05-24 10:10:48 +02:00
|
|
|
/* Table of rename/copy destinations */
|
|
|
|
|
|
|
|
static struct diff_rename_dst {
|
|
|
|
struct diff_filespec *two;
|
|
|
|
struct diff_filepair *pair;
|
|
|
|
} *rename_dst;
|
|
|
|
static int rename_dst_nr, rename_dst_alloc;
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2005-05-24 10:10:48 +02:00
|
|
|
static struct diff_rename_dst *locate_rename_dst(struct diff_filespec *two,
|
|
|
|
int insert_ok)
|
2005-05-21 11:39:09 +02:00
|
|
|
{
|
2005-05-24 10:10:48 +02:00
|
|
|
int first, last;
|
|
|
|
|
|
|
|
first = 0;
|
|
|
|
last = rename_dst_nr;
|
|
|
|
while (last > first) {
|
|
|
|
int next = (last + first) >> 1;
|
|
|
|
struct diff_rename_dst *dst = &(rename_dst[next]);
|
|
|
|
int cmp = strcmp(two->path, dst->two->path);
|
|
|
|
if (!cmp)
|
|
|
|
return dst;
|
|
|
|
if (cmp < 0) {
|
|
|
|
last = next;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
first = next+1;
|
|
|
|
}
|
|
|
|
/* not found */
|
|
|
|
if (!insert_ok)
|
|
|
|
return NULL;
|
|
|
|
/* insert to make it at "first" */
|
|
|
|
if (rename_dst_alloc <= rename_dst_nr) {
|
|
|
|
rename_dst_alloc = alloc_nr(rename_dst_alloc);
|
|
|
|
rename_dst = xrealloc(rename_dst,
|
|
|
|
rename_dst_alloc * sizeof(*rename_dst));
|
|
|
|
}
|
|
|
|
rename_dst_nr++;
|
|
|
|
if (first < rename_dst_nr)
|
|
|
|
memmove(rename_dst + first + 1, rename_dst + first,
|
|
|
|
(rename_dst_nr - first - 1) * sizeof(*rename_dst));
|
2005-09-16 01:13:43 +02:00
|
|
|
rename_dst[first].two = alloc_filespec(two->path);
|
|
|
|
fill_filespec(rename_dst[first].two, two->sha1, two->mode);
|
2005-05-24 10:10:48 +02:00
|
|
|
rename_dst[first].pair = NULL;
|
|
|
|
return &(rename_dst[first]);
|
2005-05-21 11:39:09 +02:00
|
|
|
}
|
|
|
|
|
2005-05-28 00:55:55 +02:00
|
|
|
/* Table of rename/copy src files */
|
2005-05-24 10:10:48 +02:00
|
|
|
static struct diff_rename_src {
|
|
|
|
struct diff_filespec *one;
|
2006-04-09 05:17:46 +02:00
|
|
|
unsigned short score; /* to remember the break score */
|
2005-05-24 10:10:48 +02:00
|
|
|
} *rename_src;
|
|
|
|
static int rename_src_nr, rename_src_alloc;
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2005-05-28 00:55:55 +02:00
|
|
|
static struct diff_rename_src *register_rename_src(struct diff_filespec *one,
|
2006-04-09 05:17:46 +02:00
|
|
|
unsigned short score)
|
2005-05-24 10:10:48 +02:00
|
|
|
{
|
|
|
|
int first, last;
|
|
|
|
|
|
|
|
first = 0;
|
|
|
|
last = rename_src_nr;
|
|
|
|
while (last > first) {
|
|
|
|
int next = (last + first) >> 1;
|
|
|
|
struct diff_rename_src *src = &(rename_src[next]);
|
|
|
|
int cmp = strcmp(one->path, src->one->path);
|
|
|
|
if (!cmp)
|
|
|
|
return src;
|
|
|
|
if (cmp < 0) {
|
|
|
|
last = next;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
first = next+1;
|
|
|
|
}
|
2005-05-28 00:55:55 +02:00
|
|
|
|
2005-05-24 10:10:48 +02:00
|
|
|
/* insert to make it at "first" */
|
|
|
|
if (rename_src_alloc <= rename_src_nr) {
|
|
|
|
rename_src_alloc = alloc_nr(rename_src_alloc);
|
|
|
|
rename_src = xrealloc(rename_src,
|
|
|
|
rename_src_alloc * sizeof(*rename_src));
|
2005-05-21 11:39:09 +02:00
|
|
|
}
|
2005-05-24 10:10:48 +02:00
|
|
|
rename_src_nr++;
|
|
|
|
if (first < rename_src_nr)
|
|
|
|
memmove(rename_src + first + 1, rename_src + first,
|
|
|
|
(rename_src_nr - first - 1) * sizeof(*rename_src));
|
|
|
|
rename_src[first].one = one;
|
2006-04-09 05:17:46 +02:00
|
|
|
rename_src[first].score = score;
|
2005-05-24 10:10:48 +02:00
|
|
|
return &(rename_src[first]);
|
2005-05-21 11:39:09 +02:00
|
|
|
}
|
|
|
|
|
2007-06-21 13:52:11 +02:00
|
|
|
static int basename_same(struct diff_filespec *src, struct diff_filespec *dst)
|
|
|
|
{
|
|
|
|
int src_len = strlen(src->path), dst_len = strlen(dst->path);
|
|
|
|
while (src_len && dst_len) {
|
|
|
|
char c1 = src->path[--src_len];
|
|
|
|
char c2 = dst->path[--dst_len];
|
|
|
|
if (c1 != c2)
|
|
|
|
return 0;
|
|
|
|
if (c1 == '/')
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return (!src_len || src->path[src_len - 1] == '/') &&
|
|
|
|
(!dst_len || dst->path[dst_len - 1] == '/');
|
|
|
|
}
|
|
|
|
|
2005-05-21 11:39:09 +02:00
|
|
|
struct diff_score {
|
2005-05-24 10:10:48 +02:00
|
|
|
int src; /* index in rename_src */
|
|
|
|
int dst; /* index in rename_dst */
|
2005-05-21 11:39:09 +02:00
|
|
|
int score;
|
2007-06-25 00:23:28 +02:00
|
|
|
int name_score;
|
2005-05-21 11:39:09 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
static int estimate_similarity(struct diff_filespec *src,
|
|
|
|
struct diff_filespec *dst,
|
|
|
|
int minimum_score)
|
|
|
|
{
|
|
|
|
/* src points at a file that existed in the original tree (or
|
|
|
|
* optionally a file in the destination tree) and dst points
|
|
|
|
* at a newly created file. They may be quite similar, in which
|
|
|
|
* case we want to say src is renamed to dst or src is copied into
|
|
|
|
* dst, and then some edit has been applied to dst.
|
|
|
|
*
|
|
|
|
* Compare them and return how similar they are, representing
|
2005-05-28 00:56:38 +02:00
|
|
|
* the score as an integer between 0 and MAX_SCORE.
|
|
|
|
*
|
|
|
|
* When there is an exact match, it is considered a better
|
|
|
|
* match than anything else; the destination does not even
|
|
|
|
* call into this function in that case.
|
2005-05-21 11:39:09 +02:00
|
|
|
*/
|
2006-03-13 07:26:34 +01:00
|
|
|
unsigned long max_size, delta_size, base_size, src_copied, literal_added;
|
2005-06-29 01:58:27 +02:00
|
|
|
unsigned long delta_limit;
|
2005-05-21 11:39:09 +02:00
|
|
|
int score;
|
|
|
|
|
2005-05-23 06:24:49 +02:00
|
|
|
/* We deal only with regular files. Symlink renames are handled
|
|
|
|
* only when they are exact matches --- in other words, no edits
|
|
|
|
* after renaming.
|
|
|
|
*/
|
|
|
|
if (!S_ISREG(src->mode) || !S_ISREG(dst->mode))
|
|
|
|
return 0;
|
|
|
|
|
2007-10-27 01:51:28 +02:00
|
|
|
/*
|
|
|
|
* Need to check that source and destination sizes are
|
|
|
|
* filled in before comparing them.
|
|
|
|
*
|
|
|
|
* If we already have "cnt_data" filled in, we know it's
|
|
|
|
* all good (avoid checking the size for zero, as that
|
|
|
|
* is a possible size - we really should have a flag to
|
|
|
|
* say whether the size is valid or not!)
|
|
|
|
*/
|
|
|
|
if (!src->cnt_data && diff_populate_filespec(src, 0))
|
|
|
|
return 0;
|
|
|
|
if (!dst->cnt_data && diff_populate_filespec(dst, 0))
|
|
|
|
return 0;
|
|
|
|
|
2006-03-13 07:26:34 +01:00
|
|
|
max_size = ((src->size > dst->size) ? src->size : dst->size);
|
2005-05-22 00:55:18 +02:00
|
|
|
base_size = ((src->size < dst->size) ? src->size : dst->size);
|
2006-03-13 07:26:34 +01:00
|
|
|
delta_size = max_size - base_size;
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2005-05-22 00:55:18 +02:00
|
|
|
/* We would not consider edits that change the file size so
|
|
|
|
* drastically. delta_size must be smaller than
|
2005-05-22 10:31:28 +02:00
|
|
|
* (MAX_SCORE-minimum_score)/MAX_SCORE * min(src->size, dst->size).
|
2005-05-28 00:56:38 +02:00
|
|
|
*
|
2005-05-22 00:55:18 +02:00
|
|
|
* Note that base_size == 0 case is handled here already
|
|
|
|
* and the final score computation below would not have a
|
|
|
|
* divide-by-zero issue.
|
2005-05-21 11:39:09 +02:00
|
|
|
*/
|
2005-05-22 10:31:28 +02:00
|
|
|
if (base_size * (MAX_SCORE-minimum_score) < delta_size * MAX_SCORE)
|
2005-05-21 11:39:09 +02:00
|
|
|
return 0;
|
|
|
|
|
2007-03-07 02:44:37 +01:00
|
|
|
delta_limit = (unsigned long)
|
|
|
|
(base_size * (MAX_SCORE-minimum_score) / MAX_SCORE);
|
2007-06-29 07:54:37 +02:00
|
|
|
if (diffcore_count_changes(src, dst,
|
2006-03-12 12:22:10 +01:00
|
|
|
&src->cnt_data, &dst->cnt_data,
|
2006-03-01 01:01:36 +01:00
|
|
|
delta_limit,
|
|
|
|
&src_copied, &literal_added))
|
2005-05-24 21:09:32 +02:00
|
|
|
return 0;
|
2005-06-03 10:36:03 +02:00
|
|
|
|
2006-03-03 07:11:25 +01:00
|
|
|
/* How similar are they?
|
|
|
|
* what percentage of material in dst are from source?
|
2005-05-21 11:39:09 +02:00
|
|
|
*/
|
2006-03-13 07:26:34 +01:00
|
|
|
if (!dst->size)
|
2006-03-03 07:11:25 +01:00
|
|
|
score = 0; /* should not happen */
|
2007-06-25 00:23:28 +02:00
|
|
|
else
|
2007-03-07 02:44:37 +01:00
|
|
|
score = (int)(src_copied * MAX_SCORE / max_size);
|
2005-05-21 11:39:09 +02:00
|
|
|
return score;
|
|
|
|
}
|
|
|
|
|
2005-09-16 01:13:43 +02:00
|
|
|
static void record_rename_pair(int dst_index, int src_index, int score)
|
2005-05-21 11:39:09 +02:00
|
|
|
{
|
2007-10-25 20:19:10 +02:00
|
|
|
struct diff_filespec *src, *dst;
|
2005-05-24 10:10:48 +02:00
|
|
|
struct diff_filepair *dp;
|
[PATCH] Rename/copy detection fix.
The rename/copy detection logic in earlier round was only good
enough to show patch output and discussion on the mailing list
about the diff-raw format updates revealed many problems with
it. This patch fixes all the ones known to me, without making
things I want to do later impossible, mostly related to patch
reordering.
(1) Earlier rename/copy detector determined which one is rename
and which one is copy too early, which made it impossible
to later introduce diffcore transformers to reorder
patches. This patch fixes it by moving that logic to the
very end of the processing.
(2) Earlier output routine diff_flush() was pruning all the
"no-change" entries indiscriminatingly. This was done due
to my false assumption that one of the requirements in the
diff-raw output was not to show such an entry (which
resulted in my incorrect comment about "diff-helper never
being able to be equivalent to built-in diff driver"). My
special thanks go to Linus for correcting me about this.
When we produce diff-raw output, for the downstream to be
able to tell renames from copies, sometimes it _is_
necessary to output "no-change" entries, and this patch
adds diffcore_prune() function for doing it.
(3) Earlier diff_filepair structure was trying to be not too
specific about rename/copy operations, but the purpose of
the structure was to record one or two paths, which _was_
indeed about rename/copy. This patch discards xfrm_msg
field which was trying to be generic for this wrong reason,
and introduces a couple of fields (rename_score and
rename_rank) that are explicitly specific to rename/copy
logic. One thing to note is that the information in a
single diff_filepair structure _still_ does not distinguish
renames from copies, and it is deliberately so. This is to
allow patches to be reordered in later stages.
(4) This patch also adds some tests about diff-raw format
output and makes sure that necessary "no-change" entries
appear on the output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-23 06:26:09 +02:00
|
|
|
|
2005-05-24 10:10:48 +02:00
|
|
|
if (rename_dst[dst_index].pair)
|
|
|
|
die("internal error: dst already matched.");
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2005-05-24 10:10:48 +02:00
|
|
|
src = rename_src[src_index].one;
|
2007-10-25 20:20:56 +02:00
|
|
|
src->rename_used++;
|
2007-10-25 20:19:10 +02:00
|
|
|
src->count++;
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2005-05-24 10:10:48 +02:00
|
|
|
dst = rename_dst[dst_index].two;
|
2007-10-25 20:19:10 +02:00
|
|
|
dst->count++;
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2007-10-25 20:19:10 +02:00
|
|
|
dp = diff_queue(NULL, src, dst);
|
2006-08-03 21:01:01 +02:00
|
|
|
dp->renamed_pair = 1;
|
2006-04-09 05:17:46 +02:00
|
|
|
if (!strcmp(src->path, dst->path))
|
|
|
|
dp->score = rename_src[src_index].score;
|
|
|
|
else
|
|
|
|
dp->score = score;
|
2005-05-24 10:10:48 +02:00
|
|
|
rename_dst[dst_index].pair = dp;
|
2005-05-21 11:39:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We sort the rename similarity matrix with the score, in descending
|
2005-05-28 00:55:55 +02:00
|
|
|
* order (the most similar first).
|
2005-05-21 11:39:09 +02:00
|
|
|
*/
|
|
|
|
static int score_compare(const void *a_, const void *b_)
|
|
|
|
{
|
|
|
|
const struct diff_score *a = a_, *b = b_;
|
2007-06-25 00:23:28 +02:00
|
|
|
|
|
|
|
if (a->score == b->score)
|
|
|
|
return b->name_score - a->name_score;
|
|
|
|
|
2005-05-21 11:39:09 +02:00
|
|
|
return b->score - a->score;
|
|
|
|
}
|
|
|
|
|
2007-10-25 20:23:26 +02:00
|
|
|
struct file_similarity {
|
|
|
|
int src_dst, index;
|
|
|
|
struct diff_filespec *filespec;
|
|
|
|
struct file_similarity *next;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int find_identical_files(struct file_similarity *src,
|
|
|
|
struct file_similarity *dst)
|
|
|
|
{
|
|
|
|
int renames = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Walk over all the destinations ...
|
|
|
|
*/
|
|
|
|
do {
|
Fix a pathological case in git detecting proper renames
Kumar Gala had a case in the u-boot archive with multiple renames of files
with identical contents, and git would turn those into multiple "copy"
operations of one of the sources, and just deleting the other sources.
This patch makes the git exact rename detection prefer to spread out the
renames over the multiple sources, rather than do multiple copies of one
source.
NOTE! The changes are a bit larger than required, because I also renamed
the variables named "one" and "two" to "target" and "source" respectively.
That makes the logic easier to follow, especially as the "one" was
illogically the target and not the soruce, for purely historical reasons
(this piece of code used to traverse over sources and targets in the wrong
order, and when we fixed that, we didn't fix the names back then. So I
fixed them now).
The important part of this change is just the trivial score calculations
for when files have identical contents:
/* Give higher scores to sources that haven't been used already */
score = !source->rename_used;
score += basename_same(source, target);
and when we have multiple choices we'll now pick the choice that gets the
best rename score, rather than only looking at whether the basename
matched.
It's worth noting a few gotchas:
- this scoring is currently only done for the "exact match" case.
In particular, in Kumar's example, even after this patch, the inexact
match case is still done as a copy+delete rather than as two renames:
delete mode 100644 board/cds/mpc8555cds/u-boot.lds
copy board/{cds => freescale}/mpc8541cds/u-boot.lds (97%)
rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (97%)
because apparently the "cds/mpc8541cds/u-boot.lds" copy looked
a bit more similar to both end results. That said, I *suspect* we just
have the exact same issue there - the similarity analysis just gave
identical (or at least very _close_ to identical) similarity points,
and we do not have any logic to prefer multiple renames over a
copy/delete there.
That is a separate patch.
- When you have identical contents and identical basenames, the actual
entry that is chosen is still picked fairly "at random" for the first
one (but the subsequent ones will prefer entries that haven't already
been used).
It's not actually really random, in that it actually depends on the
relative alphabetical order of the files (which in turn will have
impacted the order that the entries got hashed!), so it gives
consistent results that can be explained. But I wanted to point it out
as an issue for when anybody actually does cross-renames.
In Kumar's case the choice is the right one (and for a single normal
directory rename it should always be, since the relative alphabetical
sorting of the files will be identical), and we now get:
rename board/{cds => freescale}/mpc8541cds/init.S (100%)
rename board/{cds => freescale}/mpc8548cds/init.S (100%)
which is the "expected" answer. However, it might still be better to
change the pedantic "exact same basename" on/off choice into a more
graduated "how similar are the pathnames" scoring situation, in order
to be more likely to get the exact rename choice that people *expect*
to see, rather than other alternatives that may *technically* be
equally good, but are surprising to a human.
It's also unclear whether we should consider "basenames are equal" or
"have already used this as a source" to be more important. This gives them
equal weight, but I suspect we might want to just multiple the "basenames
are equal" weight by two, or something, to prefer equal basenames even if
that causes a copy/delete pair. I dunno.
Anyway, what I'm just saying in a really long-winded manner is that I
think this is right as-is, but it's not the complete solution, and it may
want some further tweaking in the future.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-29 22:30:13 +01:00
|
|
|
struct diff_filespec *target = dst->filespec;
|
2007-10-25 20:23:26 +02:00
|
|
|
struct file_similarity *p, *best;
|
Fix a pathological case in git detecting proper renames
Kumar Gala had a case in the u-boot archive with multiple renames of files
with identical contents, and git would turn those into multiple "copy"
operations of one of the sources, and just deleting the other sources.
This patch makes the git exact rename detection prefer to spread out the
renames over the multiple sources, rather than do multiple copies of one
source.
NOTE! The changes are a bit larger than required, because I also renamed
the variables named "one" and "two" to "target" and "source" respectively.
That makes the logic easier to follow, especially as the "one" was
illogically the target and not the soruce, for purely historical reasons
(this piece of code used to traverse over sources and targets in the wrong
order, and when we fixed that, we didn't fix the names back then. So I
fixed them now).
The important part of this change is just the trivial score calculations
for when files have identical contents:
/* Give higher scores to sources that haven't been used already */
score = !source->rename_used;
score += basename_same(source, target);
and when we have multiple choices we'll now pick the choice that gets the
best rename score, rather than only looking at whether the basename
matched.
It's worth noting a few gotchas:
- this scoring is currently only done for the "exact match" case.
In particular, in Kumar's example, even after this patch, the inexact
match case is still done as a copy+delete rather than as two renames:
delete mode 100644 board/cds/mpc8555cds/u-boot.lds
copy board/{cds => freescale}/mpc8541cds/u-boot.lds (97%)
rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (97%)
because apparently the "cds/mpc8541cds/u-boot.lds" copy looked
a bit more similar to both end results. That said, I *suspect* we just
have the exact same issue there - the similarity analysis just gave
identical (or at least very _close_ to identical) similarity points,
and we do not have any logic to prefer multiple renames over a
copy/delete there.
That is a separate patch.
- When you have identical contents and identical basenames, the actual
entry that is chosen is still picked fairly "at random" for the first
one (but the subsequent ones will prefer entries that haven't already
been used).
It's not actually really random, in that it actually depends on the
relative alphabetical order of the files (which in turn will have
impacted the order that the entries got hashed!), so it gives
consistent results that can be explained. But I wanted to point it out
as an issue for when anybody actually does cross-renames.
In Kumar's case the choice is the right one (and for a single normal
directory rename it should always be, since the relative alphabetical
sorting of the files will be identical), and we now get:
rename board/{cds => freescale}/mpc8541cds/init.S (100%)
rename board/{cds => freescale}/mpc8548cds/init.S (100%)
which is the "expected" answer. However, it might still be better to
change the pedantic "exact same basename" on/off choice into a more
graduated "how similar are the pathnames" scoring situation, in order
to be more likely to get the exact rename choice that people *expect*
to see, rather than other alternatives that may *technically* be
equally good, but are surprising to a human.
It's also unclear whether we should consider "basenames are equal" or
"have already used this as a source" to be more important. This gives them
equal weight, but I suspect we might want to just multiple the "basenames
are equal" weight by two, or something, to prefer equal basenames even if
that causes a copy/delete pair. I dunno.
Anyway, what I'm just saying in a really long-winded manner is that I
think this is right as-is, but it's not the complete solution, and it may
want some further tweaking in the future.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-29 22:30:13 +01:00
|
|
|
int i = 100, best_score = -1;
|
2007-10-25 20:23:26 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* .. to find the best source match
|
|
|
|
*/
|
|
|
|
best = NULL;
|
|
|
|
for (p = src; p; p = p->next) {
|
Fix a pathological case in git detecting proper renames
Kumar Gala had a case in the u-boot archive with multiple renames of files
with identical contents, and git would turn those into multiple "copy"
operations of one of the sources, and just deleting the other sources.
This patch makes the git exact rename detection prefer to spread out the
renames over the multiple sources, rather than do multiple copies of one
source.
NOTE! The changes are a bit larger than required, because I also renamed
the variables named "one" and "two" to "target" and "source" respectively.
That makes the logic easier to follow, especially as the "one" was
illogically the target and not the soruce, for purely historical reasons
(this piece of code used to traverse over sources and targets in the wrong
order, and when we fixed that, we didn't fix the names back then. So I
fixed them now).
The important part of this change is just the trivial score calculations
for when files have identical contents:
/* Give higher scores to sources that haven't been used already */
score = !source->rename_used;
score += basename_same(source, target);
and when we have multiple choices we'll now pick the choice that gets the
best rename score, rather than only looking at whether the basename
matched.
It's worth noting a few gotchas:
- this scoring is currently only done for the "exact match" case.
In particular, in Kumar's example, even after this patch, the inexact
match case is still done as a copy+delete rather than as two renames:
delete mode 100644 board/cds/mpc8555cds/u-boot.lds
copy board/{cds => freescale}/mpc8541cds/u-boot.lds (97%)
rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (97%)
because apparently the "cds/mpc8541cds/u-boot.lds" copy looked
a bit more similar to both end results. That said, I *suspect* we just
have the exact same issue there - the similarity analysis just gave
identical (or at least very _close_ to identical) similarity points,
and we do not have any logic to prefer multiple renames over a
copy/delete there.
That is a separate patch.
- When you have identical contents and identical basenames, the actual
entry that is chosen is still picked fairly "at random" for the first
one (but the subsequent ones will prefer entries that haven't already
been used).
It's not actually really random, in that it actually depends on the
relative alphabetical order of the files (which in turn will have
impacted the order that the entries got hashed!), so it gives
consistent results that can be explained. But I wanted to point it out
as an issue for when anybody actually does cross-renames.
In Kumar's case the choice is the right one (and for a single normal
directory rename it should always be, since the relative alphabetical
sorting of the files will be identical), and we now get:
rename board/{cds => freescale}/mpc8541cds/init.S (100%)
rename board/{cds => freescale}/mpc8548cds/init.S (100%)
which is the "expected" answer. However, it might still be better to
change the pedantic "exact same basename" on/off choice into a more
graduated "how similar are the pathnames" scoring situation, in order
to be more likely to get the exact rename choice that people *expect*
to see, rather than other alternatives that may *technically* be
equally good, but are surprising to a human.
It's also unclear whether we should consider "basenames are equal" or
"have already used this as a source" to be more important. This gives them
equal weight, but I suspect we might want to just multiple the "basenames
are equal" weight by two, or something, to prefer equal basenames even if
that causes a copy/delete pair. I dunno.
Anyway, what I'm just saying in a really long-winded manner is that I
think this is right as-is, but it's not the complete solution, and it may
want some further tweaking in the future.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-29 22:30:13 +01:00
|
|
|
int score;
|
|
|
|
struct diff_filespec *source = p->filespec;
|
2007-10-25 20:23:26 +02:00
|
|
|
|
|
|
|
/* False hash collission? */
|
Fix a pathological case in git detecting proper renames
Kumar Gala had a case in the u-boot archive with multiple renames of files
with identical contents, and git would turn those into multiple "copy"
operations of one of the sources, and just deleting the other sources.
This patch makes the git exact rename detection prefer to spread out the
renames over the multiple sources, rather than do multiple copies of one
source.
NOTE! The changes are a bit larger than required, because I also renamed
the variables named "one" and "two" to "target" and "source" respectively.
That makes the logic easier to follow, especially as the "one" was
illogically the target and not the soruce, for purely historical reasons
(this piece of code used to traverse over sources and targets in the wrong
order, and when we fixed that, we didn't fix the names back then. So I
fixed them now).
The important part of this change is just the trivial score calculations
for when files have identical contents:
/* Give higher scores to sources that haven't been used already */
score = !source->rename_used;
score += basename_same(source, target);
and when we have multiple choices we'll now pick the choice that gets the
best rename score, rather than only looking at whether the basename
matched.
It's worth noting a few gotchas:
- this scoring is currently only done for the "exact match" case.
In particular, in Kumar's example, even after this patch, the inexact
match case is still done as a copy+delete rather than as two renames:
delete mode 100644 board/cds/mpc8555cds/u-boot.lds
copy board/{cds => freescale}/mpc8541cds/u-boot.lds (97%)
rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (97%)
because apparently the "cds/mpc8541cds/u-boot.lds" copy looked
a bit more similar to both end results. That said, I *suspect* we just
have the exact same issue there - the similarity analysis just gave
identical (or at least very _close_ to identical) similarity points,
and we do not have any logic to prefer multiple renames over a
copy/delete there.
That is a separate patch.
- When you have identical contents and identical basenames, the actual
entry that is chosen is still picked fairly "at random" for the first
one (but the subsequent ones will prefer entries that haven't already
been used).
It's not actually really random, in that it actually depends on the
relative alphabetical order of the files (which in turn will have
impacted the order that the entries got hashed!), so it gives
consistent results that can be explained. But I wanted to point it out
as an issue for when anybody actually does cross-renames.
In Kumar's case the choice is the right one (and for a single normal
directory rename it should always be, since the relative alphabetical
sorting of the files will be identical), and we now get:
rename board/{cds => freescale}/mpc8541cds/init.S (100%)
rename board/{cds => freescale}/mpc8548cds/init.S (100%)
which is the "expected" answer. However, it might still be better to
change the pedantic "exact same basename" on/off choice into a more
graduated "how similar are the pathnames" scoring situation, in order
to be more likely to get the exact rename choice that people *expect*
to see, rather than other alternatives that may *technically* be
equally good, but are surprising to a human.
It's also unclear whether we should consider "basenames are equal" or
"have already used this as a source" to be more important. This gives them
equal weight, but I suspect we might want to just multiple the "basenames
are equal" weight by two, or something, to prefer equal basenames even if
that causes a copy/delete pair. I dunno.
Anyway, what I'm just saying in a really long-winded manner is that I
think this is right as-is, but it's not the complete solution, and it may
want some further tweaking in the future.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-29 22:30:13 +01:00
|
|
|
if (hashcmp(source->sha1, target->sha1))
|
2007-10-25 20:23:26 +02:00
|
|
|
continue;
|
|
|
|
/* Non-regular files? If so, the modes must match! */
|
Fix a pathological case in git detecting proper renames
Kumar Gala had a case in the u-boot archive with multiple renames of files
with identical contents, and git would turn those into multiple "copy"
operations of one of the sources, and just deleting the other sources.
This patch makes the git exact rename detection prefer to spread out the
renames over the multiple sources, rather than do multiple copies of one
source.
NOTE! The changes are a bit larger than required, because I also renamed
the variables named "one" and "two" to "target" and "source" respectively.
That makes the logic easier to follow, especially as the "one" was
illogically the target and not the soruce, for purely historical reasons
(this piece of code used to traverse over sources and targets in the wrong
order, and when we fixed that, we didn't fix the names back then. So I
fixed them now).
The important part of this change is just the trivial score calculations
for when files have identical contents:
/* Give higher scores to sources that haven't been used already */
score = !source->rename_used;
score += basename_same(source, target);
and when we have multiple choices we'll now pick the choice that gets the
best rename score, rather than only looking at whether the basename
matched.
It's worth noting a few gotchas:
- this scoring is currently only done for the "exact match" case.
In particular, in Kumar's example, even after this patch, the inexact
match case is still done as a copy+delete rather than as two renames:
delete mode 100644 board/cds/mpc8555cds/u-boot.lds
copy board/{cds => freescale}/mpc8541cds/u-boot.lds (97%)
rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (97%)
because apparently the "cds/mpc8541cds/u-boot.lds" copy looked
a bit more similar to both end results. That said, I *suspect* we just
have the exact same issue there - the similarity analysis just gave
identical (or at least very _close_ to identical) similarity points,
and we do not have any logic to prefer multiple renames over a
copy/delete there.
That is a separate patch.
- When you have identical contents and identical basenames, the actual
entry that is chosen is still picked fairly "at random" for the first
one (but the subsequent ones will prefer entries that haven't already
been used).
It's not actually really random, in that it actually depends on the
relative alphabetical order of the files (which in turn will have
impacted the order that the entries got hashed!), so it gives
consistent results that can be explained. But I wanted to point it out
as an issue for when anybody actually does cross-renames.
In Kumar's case the choice is the right one (and for a single normal
directory rename it should always be, since the relative alphabetical
sorting of the files will be identical), and we now get:
rename board/{cds => freescale}/mpc8541cds/init.S (100%)
rename board/{cds => freescale}/mpc8548cds/init.S (100%)
which is the "expected" answer. However, it might still be better to
change the pedantic "exact same basename" on/off choice into a more
graduated "how similar are the pathnames" scoring situation, in order
to be more likely to get the exact rename choice that people *expect*
to see, rather than other alternatives that may *technically* be
equally good, but are surprising to a human.
It's also unclear whether we should consider "basenames are equal" or
"have already used this as a source" to be more important. This gives them
equal weight, but I suspect we might want to just multiple the "basenames
are equal" weight by two, or something, to prefer equal basenames even if
that causes a copy/delete pair. I dunno.
Anyway, what I'm just saying in a really long-winded manner is that I
think this is right as-is, but it's not the complete solution, and it may
want some further tweaking in the future.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-29 22:30:13 +01:00
|
|
|
if (!S_ISREG(source->mode) || !S_ISREG(target->mode)) {
|
|
|
|
if (source->mode != target->mode)
|
2007-10-25 20:23:26 +02:00
|
|
|
continue;
|
|
|
|
}
|
Fix a pathological case in git detecting proper renames
Kumar Gala had a case in the u-boot archive with multiple renames of files
with identical contents, and git would turn those into multiple "copy"
operations of one of the sources, and just deleting the other sources.
This patch makes the git exact rename detection prefer to spread out the
renames over the multiple sources, rather than do multiple copies of one
source.
NOTE! The changes are a bit larger than required, because I also renamed
the variables named "one" and "two" to "target" and "source" respectively.
That makes the logic easier to follow, especially as the "one" was
illogically the target and not the soruce, for purely historical reasons
(this piece of code used to traverse over sources and targets in the wrong
order, and when we fixed that, we didn't fix the names back then. So I
fixed them now).
The important part of this change is just the trivial score calculations
for when files have identical contents:
/* Give higher scores to sources that haven't been used already */
score = !source->rename_used;
score += basename_same(source, target);
and when we have multiple choices we'll now pick the choice that gets the
best rename score, rather than only looking at whether the basename
matched.
It's worth noting a few gotchas:
- this scoring is currently only done for the "exact match" case.
In particular, in Kumar's example, even after this patch, the inexact
match case is still done as a copy+delete rather than as two renames:
delete mode 100644 board/cds/mpc8555cds/u-boot.lds
copy board/{cds => freescale}/mpc8541cds/u-boot.lds (97%)
rename board/{cds/mpc8541cds => freescale/mpc8555cds}/u-boot.lds (97%)
because apparently the "cds/mpc8541cds/u-boot.lds" copy looked
a bit more similar to both end results. That said, I *suspect* we just
have the exact same issue there - the similarity analysis just gave
identical (or at least very _close_ to identical) similarity points,
and we do not have any logic to prefer multiple renames over a
copy/delete there.
That is a separate patch.
- When you have identical contents and identical basenames, the actual
entry that is chosen is still picked fairly "at random" for the first
one (but the subsequent ones will prefer entries that haven't already
been used).
It's not actually really random, in that it actually depends on the
relative alphabetical order of the files (which in turn will have
impacted the order that the entries got hashed!), so it gives
consistent results that can be explained. But I wanted to point it out
as an issue for when anybody actually does cross-renames.
In Kumar's case the choice is the right one (and for a single normal
directory rename it should always be, since the relative alphabetical
sorting of the files will be identical), and we now get:
rename board/{cds => freescale}/mpc8541cds/init.S (100%)
rename board/{cds => freescale}/mpc8548cds/init.S (100%)
which is the "expected" answer. However, it might still be better to
change the pedantic "exact same basename" on/off choice into a more
graduated "how similar are the pathnames" scoring situation, in order
to be more likely to get the exact rename choice that people *expect*
to see, rather than other alternatives that may *technically* be
equally good, but are surprising to a human.
It's also unclear whether we should consider "basenames are equal" or
"have already used this as a source" to be more important. This gives them
equal weight, but I suspect we might want to just multiple the "basenames
are equal" weight by two, or something, to prefer equal basenames even if
that causes a copy/delete pair. I dunno.
Anyway, what I'm just saying in a really long-winded manner is that I
think this is right as-is, but it's not the complete solution, and it may
want some further tweaking in the future.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-29 22:30:13 +01:00
|
|
|
/* Give higher scores to sources that haven't been used already */
|
|
|
|
score = !source->rename_used;
|
|
|
|
score += basename_same(source, target);
|
|
|
|
if (score > best_score) {
|
|
|
|
best = p;
|
|
|
|
best_score = score;
|
|
|
|
if (score == 2)
|
|
|
|
break;
|
|
|
|
}
|
2007-10-25 20:23:26 +02:00
|
|
|
|
|
|
|
/* Too many identical alternatives? Pick one */
|
|
|
|
if (!--i)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (best) {
|
|
|
|
record_rename_pair(dst->index, best->index, MAX_SCORE);
|
|
|
|
renames++;
|
|
|
|
}
|
|
|
|
} while ((dst = dst->next) != NULL);
|
|
|
|
return renames;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void free_similarity_list(struct file_similarity *p)
|
|
|
|
{
|
|
|
|
while (p) {
|
|
|
|
struct file_similarity *entry = p;
|
|
|
|
p = p->next;
|
|
|
|
free(entry);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int find_same_files(void *ptr)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct file_similarity *p = ptr;
|
|
|
|
struct file_similarity *src = NULL, *dst = NULL;
|
|
|
|
|
|
|
|
/* Split the hash list up into sources and destinations */
|
|
|
|
do {
|
|
|
|
struct file_similarity *entry = p;
|
|
|
|
p = p->next;
|
|
|
|
if (entry->src_dst < 0) {
|
|
|
|
entry->next = src;
|
|
|
|
src = entry;
|
|
|
|
} else {
|
|
|
|
entry->next = dst;
|
|
|
|
dst = entry;
|
|
|
|
}
|
|
|
|
} while (p);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have both sources *and* destinations, see if
|
|
|
|
* we can match them up
|
|
|
|
*/
|
|
|
|
ret = (src && dst) ? find_identical_files(src, dst) : 0;
|
|
|
|
|
|
|
|
/* Free the hashes and return the number of renames found */
|
|
|
|
free_similarity_list(src);
|
|
|
|
free_similarity_list(dst);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned int hash_filespec(struct diff_filespec *filespec)
|
|
|
|
{
|
|
|
|
unsigned int hash;
|
|
|
|
if (!filespec->sha1_valid) {
|
|
|
|
if (diff_populate_filespec(filespec, 0))
|
|
|
|
return 0;
|
|
|
|
hash_sha1_file(filespec->data, filespec->size, "blob", filespec->sha1);
|
|
|
|
}
|
|
|
|
memcpy(&hash, filespec->sha1, sizeof(hash));
|
|
|
|
return hash;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void insert_file_table(struct hash_table *table, int src_dst, int index, struct diff_filespec *filespec)
|
|
|
|
{
|
|
|
|
void **pos;
|
|
|
|
unsigned int hash;
|
|
|
|
struct file_similarity *entry = xmalloc(sizeof(*entry));
|
|
|
|
|
|
|
|
entry->src_dst = src_dst;
|
|
|
|
entry->index = index;
|
|
|
|
entry->filespec = filespec;
|
|
|
|
entry->next = NULL;
|
|
|
|
|
|
|
|
hash = hash_filespec(filespec);
|
|
|
|
pos = insert_hash(hash, entry, table);
|
|
|
|
|
|
|
|
/* We already had an entry there? */
|
|
|
|
if (pos) {
|
|
|
|
entry->next = *pos;
|
|
|
|
*pos = entry;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-10-25 20:17:55 +02:00
|
|
|
/*
|
|
|
|
* Find exact renames first.
|
|
|
|
*
|
|
|
|
* The first round matches up the up-to-date entries,
|
|
|
|
* and then during the second round we try to match
|
|
|
|
* cache-dirty entries as well.
|
|
|
|
*/
|
|
|
|
static int find_exact_renames(void)
|
|
|
|
{
|
2007-10-25 20:23:26 +02:00
|
|
|
int i;
|
|
|
|
struct hash_table file_table;
|
2007-10-25 20:17:55 +02:00
|
|
|
|
2007-10-25 20:23:26 +02:00
|
|
|
init_hash(&file_table);
|
|
|
|
for (i = 0; i < rename_src_nr; i++)
|
|
|
|
insert_file_table(&file_table, -1, i, rename_src[i].one);
|
|
|
|
|
|
|
|
for (i = 0; i < rename_dst_nr; i++)
|
|
|
|
insert_file_table(&file_table, 1, i, rename_dst[i].two);
|
|
|
|
|
|
|
|
/* Find the renames */
|
|
|
|
i = for_each_hash(&file_table, find_same_files);
|
|
|
|
|
|
|
|
/* .. and free the hash data structure */
|
|
|
|
free_hash(&file_table);
|
|
|
|
|
|
|
|
return i;
|
2007-10-25 20:17:55 +02:00
|
|
|
}
|
|
|
|
|
2005-09-21 09:18:27 +02:00
|
|
|
void diffcore_rename(struct diff_options *options)
|
2005-05-21 11:39:09 +02:00
|
|
|
{
|
2005-09-21 09:18:27 +02:00
|
|
|
int detect_rename = options->detect_rename;
|
|
|
|
int minimum_score = options->rename_score;
|
|
|
|
int rename_limit = options->rename_limit;
|
2005-05-22 04:40:36 +02:00
|
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
2005-09-16 01:13:43 +02:00
|
|
|
struct diff_queue_struct outq;
|
2005-05-21 11:39:09 +02:00
|
|
|
struct diff_score *mx;
|
2007-10-25 20:17:55 +02:00
|
|
|
int i, j, rename_count;
|
2005-05-24 10:10:48 +02:00
|
|
|
int num_create, num_src, dst_cnt;
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2005-05-22 08:33:32 +02:00
|
|
|
if (!minimum_score)
|
[PATCH] Add -B flag to diff-* brothers.
A new diffcore transformation, diffcore-break.c, is introduced.
When the -B flag is given, a patch that represents a complete
rewrite is broken into a deletion followed by a creation. This
makes it easier to review such a complete rewrite patch.
The -B flag takes the same syntax as the -M and -C flags to
specify the minimum amount of non-source material the resulting
file needs to have to be considered a complete rewrite, and
defaults to 99% if not specified.
As the new test t4008-diff-break-rewrite.sh demonstrates, if a
file is a complete rewrite, it is broken into a delete/create
pair, which can further be subjected to the usual rename
detection if -M or -C is used. For example, if file0 gets
completely rewritten to make it as if it were rather based on
file1 which itself disappeared, the following happens:
The original change looks like this:
file0 --> file0' (quite different from file0)
file1 --> /dev/null
After diffcore-break runs, it would become this:
file0 --> /dev/null
/dev/null --> file0'
file1 --> /dev/null
Then diffcore-rename matches them up:
file1 --> file0'
The internal score values are finer grained now. Earlier
maximum of 10000 has been raised to 60000; there is no user
visible changes but there is no reason to waste available bits.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-30 09:08:37 +02:00
|
|
|
minimum_score = DEFAULT_RENAME_SCORE;
|
2005-05-21 11:39:09 +02:00
|
|
|
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
2005-05-21 11:40:01 +02:00
|
|
|
struct diff_filepair *p = q->queue[i];
|
2006-11-02 09:02:11 +01:00
|
|
|
if (!DIFF_FILE_VALID(p->one)) {
|
2005-05-22 04:42:18 +02:00
|
|
|
if (!DIFF_FILE_VALID(p->two))
|
2005-05-23 06:24:49 +02:00
|
|
|
continue; /* unmerged */
|
2006-11-02 09:02:11 +01:00
|
|
|
else if (options->single_follow &&
|
|
|
|
strcmp(options->single_follow, p->two->path))
|
|
|
|
continue; /* not interested */
|
2005-05-21 11:39:09 +02:00
|
|
|
else
|
2005-05-24 10:10:48 +02:00
|
|
|
locate_rename_dst(p->two, 1);
|
2006-11-02 09:02:11 +01:00
|
|
|
}
|
2005-06-12 05:55:20 +02:00
|
|
|
else if (!DIFF_FILE_VALID(p->two)) {
|
2007-10-25 20:20:56 +02:00
|
|
|
/*
|
|
|
|
* If the source is a broken "delete", and
|
2005-06-12 05:55:20 +02:00
|
|
|
* they did not really want to get broken,
|
|
|
|
* that means the source actually stays.
|
2007-10-25 20:20:56 +02:00
|
|
|
* So we increment the "rename_used" score
|
|
|
|
* by one, to indicate ourselves as a user
|
|
|
|
*/
|
|
|
|
if (p->broken_pair && !p->score)
|
|
|
|
p->one->rename_used++;
|
|
|
|
register_rename_src(p->one, p->score);
|
|
|
|
}
|
|
|
|
else if (detect_rename == DIFF_DETECT_COPY) {
|
|
|
|
/*
|
|
|
|
* Increment the "rename_used" score by
|
|
|
|
* one, to indicate ourselves as a user.
|
2005-06-12 05:55:20 +02:00
|
|
|
*/
|
2007-10-25 20:20:56 +02:00
|
|
|
p->one->rename_used++;
|
|
|
|
register_rename_src(p->one, p->score);
|
2005-06-12 05:55:20 +02:00
|
|
|
}
|
2005-05-21 11:39:09 +02:00
|
|
|
}
|
Fix the rename detection limit checking
This adds more proper rename detection limits. Instead of just checking
the limit against the number of potential rename destinations, we verify
that the rename matrix (which is what really matters) doesn't grow
ridiculously large, and we also make sure that we don't overflow when
doing the matrix size calculation.
This also changes the default limits from unlimited, to a rename matrix
that is limited to 100 entries on a side. You can raise it with the config
entry, or by using the "-l<n>" command line flag, but at least the default
is now a sane number that avoids spending lots of time (and memory) in
situations that likely don't merit it.
The choice of default value is of course very debatable. Limiting the
rename matrix to a 100x100 size will mean that even if you have just one
obvious rename, but you also create (or delete) 10,000 files, the rename
matrix will be so big that we disable the heuristics. Sounds reasonable to
me, but let's see if people hit this (and, perhaps more importantly,
actually *care*) in real life.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14 19:39:48 +02:00
|
|
|
if (rename_dst_nr == 0 || rename_src_nr == 0)
|
2005-05-21 11:39:09 +02:00
|
|
|
goto cleanup; /* nothing to do */
|
|
|
|
|
Do exact rename detection regardless of rename limits
Now that the exact rename detection is linear-time (with a very small
constant factor to boot), there is no longer any reason to limit it by
the number of files involved.
In some trivial testing, I created a repository with a directory that
had a hundred thousand files in it (all with different contents), and
then moved that directory to show the effects of renaming 100,000 files.
With the new code, that resulted in
[torvalds@woody big-rename]$ time ~/git/git show -C | wc -l
400006
real 0m2.071s
user 0m1.520s
sys 0m0.576s
ie the code can correctly detect the hundred thousand renames in about 2
seconds (the number "400006" comes from four lines for each rename:
diff --git a/really-big-dir/file-1-1-1-1-1 b/moved-big-dir/file-1-1-1-1-1
similarity index 100%
rename from really-big-dir/file-1-1-1-1-1
rename to moved-big-dir/file-1-1-1-1-1
and the extra six lines is from a one-liner commit message and all the
commit information and spacing).
Most of those two seconds weren't even really the rename detection, it's
really all the other stuff needed to get there.
With the old code, this wouldn't have been practically possible. Doing
a pairwise check of the ten billion possible pairs would have been
prohibitively expensive. In fact, even with the rename limiter in
place, the old code would waste a lot of time just on the diff_filespec
checks, and despite not even trying to find renames, it used to look
like:
[torvalds@woody big-rename]$ time git show -C | wc -l
1400006
real 0m12.337s
user 0m12.285s
sys 0m0.192s
ie we used to take 12 seconds for this load and not even do any rename
detection! (The number 1400006 comes from fourteen lines per file moved:
seven lines each for the delete and the create of a one-liner file, and
the same extra six lines of commit information).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-25 20:24:47 +02:00
|
|
|
/*
|
|
|
|
* We really want to cull the candidates list early
|
|
|
|
* with cheap tests in order to avoid doing deltas.
|
|
|
|
*/
|
|
|
|
rename_count = find_exact_renames();
|
|
|
|
|
2007-10-27 01:56:34 +02:00
|
|
|
/* Did we only want exact renames? */
|
|
|
|
if (minimum_score == MAX_SCORE)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate how many renames are left (but all the source
|
|
|
|
* files still remain as options for rename/copies!)
|
|
|
|
*/
|
|
|
|
num_create = (rename_dst_nr - rename_count);
|
|
|
|
num_src = rename_src_nr;
|
|
|
|
|
|
|
|
/* All done? */
|
|
|
|
if (!num_create)
|
|
|
|
goto cleanup;
|
|
|
|
|
Fix the rename detection limit checking
This adds more proper rename detection limits. Instead of just checking
the limit against the number of potential rename destinations, we verify
that the rename matrix (which is what really matters) doesn't grow
ridiculously large, and we also make sure that we don't overflow when
doing the matrix size calculation.
This also changes the default limits from unlimited, to a rename matrix
that is limited to 100 entries on a side. You can raise it with the config
entry, or by using the "-l<n>" command line flag, but at least the default
is now a sane number that avoids spending lots of time (and memory) in
situations that likely don't merit it.
The choice of default value is of course very debatable. Limiting the
rename matrix to a 100x100 size will mean that even if you have just one
obvious rename, but you also create (or delete) 10,000 files, the rename
matrix will be so big that we disable the heuristics. Sounds reasonable to
me, but let's see if people hit this (and, perhaps more importantly,
actually *care*) in real life.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14 19:39:48 +02:00
|
|
|
/*
|
|
|
|
* This basically does a test for the rename matrix not
|
|
|
|
* growing larger than a "rename_limit" square matrix, ie:
|
|
|
|
*
|
2007-10-27 01:56:34 +02:00
|
|
|
* num_create * num_src > rename_limit * rename_limit
|
Fix the rename detection limit checking
This adds more proper rename detection limits. Instead of just checking
the limit against the number of potential rename destinations, we verify
that the rename matrix (which is what really matters) doesn't grow
ridiculously large, and we also make sure that we don't overflow when
doing the matrix size calculation.
This also changes the default limits from unlimited, to a rename matrix
that is limited to 100 entries on a side. You can raise it with the config
entry, or by using the "-l<n>" command line flag, but at least the default
is now a sane number that avoids spending lots of time (and memory) in
situations that likely don't merit it.
The choice of default value is of course very debatable. Limiting the
rename matrix to a 100x100 size will mean that even if you have just one
obvious rename, but you also create (or delete) 10,000 files, the rename
matrix will be so big that we disable the heuristics. Sounds reasonable to
me, but let's see if people hit this (and, perhaps more importantly,
actually *care*) in real life.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14 19:39:48 +02:00
|
|
|
*
|
|
|
|
* but handles the potential overflow case specially (and we
|
|
|
|
* assume at least 32-bit integers)
|
|
|
|
*/
|
|
|
|
if (rename_limit <= 0 || rename_limit > 32767)
|
|
|
|
rename_limit = 32767;
|
2007-10-27 01:56:34 +02:00
|
|
|
if (num_create > rename_limit && num_src > rename_limit)
|
Fix the rename detection limit checking
This adds more proper rename detection limits. Instead of just checking
the limit against the number of potential rename destinations, we verify
that the rename matrix (which is what really matters) doesn't grow
ridiculously large, and we also make sure that we don't overflow when
doing the matrix size calculation.
This also changes the default limits from unlimited, to a rename matrix
that is limited to 100 entries on a side. You can raise it with the config
entry, or by using the "-l<n>" command line flag, but at least the default
is now a sane number that avoids spending lots of time (and memory) in
situations that likely don't merit it.
The choice of default value is of course very debatable. Limiting the
rename matrix to a 100x100 size will mean that even if you have just one
obvious rename, but you also create (or delete) 10,000 files, the rename
matrix will be so big that we disable the heuristics. Sounds reasonable to
me, but let's see if people hit this (and, perhaps more importantly,
actually *care*) in real life.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14 19:39:48 +02:00
|
|
|
goto cleanup;
|
2007-10-27 01:56:34 +02:00
|
|
|
if (num_create * num_src > rename_limit * rename_limit)
|
Fix the rename detection limit checking
This adds more proper rename detection limits. Instead of just checking
the limit against the number of potential rename destinations, we verify
that the rename matrix (which is what really matters) doesn't grow
ridiculously large, and we also make sure that we don't overflow when
doing the matrix size calculation.
This also changes the default limits from unlimited, to a rename matrix
that is limited to 100 entries on a side. You can raise it with the config
entry, or by using the "-l<n>" command line flag, but at least the default
is now a sane number that avoids spending lots of time (and memory) in
situations that likely don't merit it.
The choice of default value is of course very debatable. Limiting the
rename matrix to a 100x100 size will mean that even if you have just one
obvious rename, but you also create (or delete) 10,000 files, the rename
matrix will be so big that we disable the heuristics. Sounds reasonable to
me, but let's see if people hit this (and, perhaps more importantly,
actually *care*) in real life.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-14 19:39:48 +02:00
|
|
|
goto cleanup;
|
|
|
|
|
2005-05-21 11:39:09 +02:00
|
|
|
mx = xmalloc(sizeof(*mx) * num_create * num_src);
|
2005-05-24 10:10:48 +02:00
|
|
|
for (dst_cnt = i = 0; i < rename_dst_nr; i++) {
|
2005-05-21 11:39:09 +02:00
|
|
|
int base = dst_cnt * num_src;
|
2005-05-24 10:10:48 +02:00
|
|
|
struct diff_filespec *two = rename_dst[i].two;
|
|
|
|
if (rename_dst[i].pair)
|
2005-05-21 11:39:09 +02:00
|
|
|
continue; /* dealt with exact match already. */
|
2005-05-24 10:10:48 +02:00
|
|
|
for (j = 0; j < rename_src_nr; j++) {
|
|
|
|
struct diff_filespec *one = rename_src[j].one;
|
|
|
|
struct diff_score *m = &mx[base+j];
|
|
|
|
m->src = j;
|
|
|
|
m->dst = i;
|
|
|
|
m->score = estimate_similarity(one, two,
|
|
|
|
minimum_score);
|
2007-06-25 00:23:28 +02:00
|
|
|
m->name_score = basename_same(one, two);
|
2007-10-03 06:01:03 +02:00
|
|
|
diff_free_filespec_blob(one);
|
2005-05-21 11:39:09 +02:00
|
|
|
}
|
2006-03-13 01:39:51 +01:00
|
|
|
/* We do not need the text anymore */
|
2007-10-03 06:01:03 +02:00
|
|
|
diff_free_filespec_blob(two);
|
2005-05-21 11:39:09 +02:00
|
|
|
dst_cnt++;
|
|
|
|
}
|
|
|
|
/* cost matrix sorted by most to least similar pair */
|
|
|
|
qsort(mx, num_create * num_src, sizeof(*mx), score_compare);
|
Fix a pathological case in git detecting proper renames
On Thu, 29 Nov 2007, Jeff King wrote:
>
> I think it will get worse, because you are simultaneously calculating
> all of the similarity scores bit by bit rather than doing a loop. Though
> perhaps you mean at the end you will end up with a list of src/dst pairs
> sorted by score, and you can loop over that.
Well, after thinking about this a bit, I think there's a solution that may
work well with the current thing too: instead of looping just *once* over
the list of rename pairs, loop twice - and simply refuse to do copies on
the first loop.
This trivial patch does that, and turns Kumar's test-case into a perfect
rename list.
It's not pretty, it's not smart, but it seems to work. There's something
to be said for keeping it simple and stupid.
And it should not be nearly as expensive as it may _look_. Yes, the loop
is "(i = 0; i < num_create * num_src; i++)", but the important part is
that the whole array is sorted by rename score, and we have a
if (mx[i].score < minimum_score)
break;
in it, so uthe loop actually would tend to terminate rather quickly.
Anyway, Kumar, the thing to take away from this is:
- git really doesn't even *care* about the whole "rename detection"
internally, and any commits you have done with renames are totally
independent of the heuristics we then use to *show* the renames.
- the rename detection really is for just two reasons: (a) keep humans
happy, and keep the diffs small and (b) help automatic merging across
renames. So getting renames right is certainly good, but it's more of a
"politeness" issue than a "correctness" issue, although the merge
portion of it does matter a lot sometimes.
- the important thing here is that you can commit your changes and not
worry about them being somehow "corrupted" by lack of rename detection,
even if you commit them with a version of git that doesn't do rename
detection the way you expected it. The rename detection is an
"after-the-fact" thing, not something that actually gets saved in the
repository, which is why we can change the heuristics _after_ seeing
examples, and the examples magically correct themselves!
- try out the two patches I've posted, and see if they work for you. They
pass the test-suite, and the output for your example commit looks sane,
but hey, if you have other test-cases, try them out.
Here's Kumar's pretty diffstat with both my patches:
Makefile | 6 +++---
board/{cds => freescale}/common/cadmus.c | 0
board/{cds => freescale}/common/cadmus.h | 0
board/{cds => freescale}/common/eeprom.c | 0
board/{cds => freescale}/common/eeprom.h | 0
board/{cds => freescale}/common/ft_board.c | 0
board/{cds => freescale}/common/via.c | 0
board/{cds => freescale}/common/via.h | 0
board/{cds => freescale}/mpc8541cds/Makefile | 0
board/{cds => freescale}/mpc8541cds/config.mk | 0
board/{cds => freescale}/mpc8541cds/init.S | 0
board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0
board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 ++--
board/{cds => freescale}/mpc8548cds/Makefile | 0
board/{cds => freescale}/mpc8548cds/config.mk | 0
board/{cds => freescale}/mpc8548cds/init.S | 0
board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0
board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 ++--
board/{cds => freescale}/mpc8555cds/Makefile | 0
board/{cds => freescale}/mpc8555cds/config.mk | 0
board/{cds => freescale}/mpc8555cds/init.S | 0
board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0
board/{cds => freescale}/mpc8555cds/u-boot.lds | 4 ++--
23 files changed, 9 insertions(+), 9 deletions(-)
and here it is before:
Makefile | 6 +-
board/cds/mpc8548cds/Makefile | 60 -----
board/cds/mpc8555cds/Makefile | 60 -----
board/cds/mpc8555cds/init.S | 255 --------------------
board/cds/mpc8555cds/u-boot.lds | 150 ------------
board/{cds => freescale}/common/cadmus.c | 0
board/{cds => freescale}/common/cadmus.h | 0
board/{cds => freescale}/common/eeprom.c | 0
board/{cds => freescale}/common/eeprom.h | 0
board/{cds => freescale}/common/ft_board.c | 0
board/{cds => freescale}/common/via.c | 0
board/{cds => freescale}/common/via.h | 0
board/{cds => freescale}/mpc8541cds/Makefile | 0
board/{cds => freescale}/mpc8541cds/config.mk | 0
board/{cds => freescale}/mpc8541cds/init.S | 0
board/{cds => freescale}/mpc8541cds/mpc8541cds.c | 0
board/{cds => freescale}/mpc8541cds/u-boot.lds | 4 +-
.../mpc8541cds => freescale/mpc8548cds}/Makefile | 0
board/{cds => freescale}/mpc8548cds/config.mk | 0
board/{cds => freescale}/mpc8548cds/init.S | 0
board/{cds => freescale}/mpc8548cds/mpc8548cds.c | 0
board/{cds => freescale}/mpc8548cds/u-boot.lds | 4 +-
.../mpc8541cds => freescale/mpc8555cds}/Makefile | 0
board/{cds => freescale}/mpc8555cds/config.mk | 0
.../mpc8541cds => freescale/mpc8555cds}/init.S | 0
board/{cds => freescale}/mpc8555cds/mpc8555cds.c | 0
.../mpc8541cds => freescale/mpc8555cds}/u-boot.lds | 4 +-
27 files changed, 9 insertions(+), 534 deletions(-)
so it certainly makes the diffs prettier.
Linus
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-30 01:41:09 +01:00
|
|
|
for (i = 0; i < num_create * num_src; i++) {
|
|
|
|
struct diff_rename_dst *dst = &rename_dst[mx[i].dst];
|
|
|
|
struct diff_filespec *src;
|
|
|
|
if (dst->pair)
|
|
|
|
continue; /* already done, either exact or fuzzy. */
|
|
|
|
if (mx[i].score < minimum_score)
|
|
|
|
break; /* there is no more usable pair. */
|
|
|
|
src = rename_src[mx[i].src].one;
|
|
|
|
if (src->rename_used)
|
|
|
|
continue;
|
|
|
|
record_rename_pair(mx[i].dst, mx[i].src, mx[i].score);
|
|
|
|
rename_count++;
|
|
|
|
}
|
2005-05-21 11:39:09 +02:00
|
|
|
for (i = 0; i < num_create * num_src; i++) {
|
2005-05-24 10:10:48 +02:00
|
|
|
struct diff_rename_dst *dst = &rename_dst[mx[i].dst];
|
|
|
|
if (dst->pair)
|
|
|
|
continue; /* already done, either exact or fuzzy. */
|
2005-05-21 11:39:09 +02:00
|
|
|
if (mx[i].score < minimum_score)
|
2005-05-28 00:55:55 +02:00
|
|
|
break; /* there is no more usable pair. */
|
2005-09-16 01:13:43 +02:00
|
|
|
record_rename_pair(mx[i].dst, mx[i].src, mx[i].score);
|
|
|
|
rename_count++;
|
2005-05-21 11:39:09 +02:00
|
|
|
}
|
|
|
|
free(mx);
|
|
|
|
|
2005-05-28 00:55:55 +02:00
|
|
|
cleanup:
|
2005-05-21 11:39:09 +02:00
|
|
|
/* At this point, we have found some renames and copies and they
|
2005-09-16 01:13:43 +02:00
|
|
|
* are recorded in rename_dst. The original list is still in *q.
|
2005-05-21 11:39:09 +02:00
|
|
|
*/
|
2005-05-24 10:10:48 +02:00
|
|
|
outq.queue = NULL;
|
|
|
|
outq.nr = outq.alloc = 0;
|
2005-05-21 11:39:09 +02:00
|
|
|
for (i = 0; i < q->nr; i++) {
|
2005-05-24 10:10:48 +02:00
|
|
|
struct diff_filepair *p = q->queue[i];
|
|
|
|
struct diff_filepair *pair_to_free = NULL;
|
|
|
|
|
2005-05-30 09:08:07 +02:00
|
|
|
if (!DIFF_FILE_VALID(p->one) && DIFF_FILE_VALID(p->two)) {
|
|
|
|
/*
|
|
|
|
* Creation
|
|
|
|
*
|
|
|
|
* We would output this create record if it has
|
|
|
|
* not been turned into a rename/copy already.
|
|
|
|
*/
|
|
|
|
struct diff_rename_dst *dst =
|
|
|
|
locate_rename_dst(p->two, 0);
|
|
|
|
if (dst && dst->pair) {
|
2005-05-24 10:10:48 +02:00
|
|
|
diff_q(&outq, dst->pair);
|
|
|
|
pair_to_free = p;
|
|
|
|
}
|
|
|
|
else
|
2005-05-30 09:08:07 +02:00
|
|
|
/* no matching rename/copy source, so
|
|
|
|
* record this as a creation.
|
2005-05-24 10:10:48 +02:00
|
|
|
*/
|
|
|
|
diff_q(&outq, p);
|
2005-05-21 11:39:09 +02:00
|
|
|
}
|
2005-05-30 09:08:07 +02:00
|
|
|
else if (DIFF_FILE_VALID(p->one) && !DIFF_FILE_VALID(p->two)) {
|
|
|
|
/*
|
|
|
|
* Deletion
|
|
|
|
*
|
[PATCH] Add -B flag to diff-* brothers.
A new diffcore transformation, diffcore-break.c, is introduced.
When the -B flag is given, a patch that represents a complete
rewrite is broken into a deletion followed by a creation. This
makes it easier to review such a complete rewrite patch.
The -B flag takes the same syntax as the -M and -C flags to
specify the minimum amount of non-source material the resulting
file needs to have to be considered a complete rewrite, and
defaults to 99% if not specified.
As the new test t4008-diff-break-rewrite.sh demonstrates, if a
file is a complete rewrite, it is broken into a delete/create
pair, which can further be subjected to the usual rename
detection if -M or -C is used. For example, if file0 gets
completely rewritten to make it as if it were rather based on
file1 which itself disappeared, the following happens:
The original change looks like this:
file0 --> file0' (quite different from file0)
file1 --> /dev/null
After diffcore-break runs, it would become this:
file0 --> /dev/null
/dev/null --> file0'
file1 --> /dev/null
Then diffcore-rename matches them up:
file1 --> file0'
The internal score values are finer grained now. Earlier
maximum of 10000 has been raised to 60000; there is no user
visible changes but there is no reason to waste available bits.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-30 09:08:37 +02:00
|
|
|
* We would output this delete record if:
|
|
|
|
*
|
|
|
|
* (1) this is a broken delete and the counterpart
|
|
|
|
* broken create remains in the output; or
|
2005-09-16 01:13:43 +02:00
|
|
|
* (2) this is not a broken delete, and rename_dst
|
|
|
|
* does not have a rename/copy to move p->one->path
|
|
|
|
* out of existence.
|
[PATCH] Add -B flag to diff-* brothers.
A new diffcore transformation, diffcore-break.c, is introduced.
When the -B flag is given, a patch that represents a complete
rewrite is broken into a deletion followed by a creation. This
makes it easier to review such a complete rewrite patch.
The -B flag takes the same syntax as the -M and -C flags to
specify the minimum amount of non-source material the resulting
file needs to have to be considered a complete rewrite, and
defaults to 99% if not specified.
As the new test t4008-diff-break-rewrite.sh demonstrates, if a
file is a complete rewrite, it is broken into a delete/create
pair, which can further be subjected to the usual rename
detection if -M or -C is used. For example, if file0 gets
completely rewritten to make it as if it were rather based on
file1 which itself disappeared, the following happens:
The original change looks like this:
file0 --> file0' (quite different from file0)
file1 --> /dev/null
After diffcore-break runs, it would become this:
file0 --> /dev/null
/dev/null --> file0'
file1 --> /dev/null
Then diffcore-rename matches them up:
file1 --> file0'
The internal score values are finer grained now. Earlier
maximum of 10000 has been raised to 60000; there is no user
visible changes but there is no reason to waste available bits.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-30 09:08:37 +02:00
|
|
|
*
|
|
|
|
* Otherwise, the counterpart broken create
|
|
|
|
* has been turned into a rename-edit; or
|
|
|
|
* delete did not have a matching create to
|
|
|
|
* begin with.
|
2005-05-30 09:08:07 +02:00
|
|
|
*/
|
[PATCH] Add -B flag to diff-* brothers.
A new diffcore transformation, diffcore-break.c, is introduced.
When the -B flag is given, a patch that represents a complete
rewrite is broken into a deletion followed by a creation. This
makes it easier to review such a complete rewrite patch.
The -B flag takes the same syntax as the -M and -C flags to
specify the minimum amount of non-source material the resulting
file needs to have to be considered a complete rewrite, and
defaults to 99% if not specified.
As the new test t4008-diff-break-rewrite.sh demonstrates, if a
file is a complete rewrite, it is broken into a delete/create
pair, which can further be subjected to the usual rename
detection if -M or -C is used. For example, if file0 gets
completely rewritten to make it as if it were rather based on
file1 which itself disappeared, the following happens:
The original change looks like this:
file0 --> file0' (quite different from file0)
file1 --> /dev/null
After diffcore-break runs, it would become this:
file0 --> /dev/null
/dev/null --> file0'
file1 --> /dev/null
Then diffcore-rename matches them up:
file1 --> file0'
The internal score values are finer grained now. Earlier
maximum of 10000 has been raised to 60000; there is no user
visible changes but there is no reason to waste available bits.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-30 09:08:37 +02:00
|
|
|
if (DIFF_PAIR_BROKEN(p)) {
|
|
|
|
/* broken delete */
|
|
|
|
struct diff_rename_dst *dst =
|
|
|
|
locate_rename_dst(p->one, 0);
|
|
|
|
if (dst && dst->pair)
|
|
|
|
/* counterpart is now rename/copy */
|
|
|
|
pair_to_free = p;
|
|
|
|
}
|
|
|
|
else {
|
2007-10-25 20:20:56 +02:00
|
|
|
if (p->one->rename_used)
|
[PATCH] Add -B flag to diff-* brothers.
A new diffcore transformation, diffcore-break.c, is introduced.
When the -B flag is given, a patch that represents a complete
rewrite is broken into a deletion followed by a creation. This
makes it easier to review such a complete rewrite patch.
The -B flag takes the same syntax as the -M and -C flags to
specify the minimum amount of non-source material the resulting
file needs to have to be considered a complete rewrite, and
defaults to 99% if not specified.
As the new test t4008-diff-break-rewrite.sh demonstrates, if a
file is a complete rewrite, it is broken into a delete/create
pair, which can further be subjected to the usual rename
detection if -M or -C is used. For example, if file0 gets
completely rewritten to make it as if it were rather based on
file1 which itself disappeared, the following happens:
The original change looks like this:
file0 --> file0' (quite different from file0)
file1 --> /dev/null
After diffcore-break runs, it would become this:
file0 --> /dev/null
/dev/null --> file0'
file1 --> /dev/null
Then diffcore-rename matches them up:
file1 --> file0'
The internal score values are finer grained now. Earlier
maximum of 10000 has been raised to 60000; there is no user
visible changes but there is no reason to waste available bits.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-30 09:08:37 +02:00
|
|
|
/* this path remains */
|
|
|
|
pair_to_free = p;
|
|
|
|
}
|
2005-05-30 09:08:07 +02:00
|
|
|
|
|
|
|
if (pair_to_free)
|
|
|
|
;
|
|
|
|
else
|
|
|
|
diff_q(&outq, p);
|
|
|
|
}
|
2005-05-24 10:10:48 +02:00
|
|
|
else if (!diff_unmodified_pair(p))
|
2005-05-28 00:55:55 +02:00
|
|
|
/* all the usual ones need to be kept */
|
2005-05-24 10:10:48 +02:00
|
|
|
diff_q(&outq, p);
|
2005-05-28 00:55:55 +02:00
|
|
|
else
|
|
|
|
/* no need to keep unmodified pairs */
|
|
|
|
pair_to_free = p;
|
|
|
|
|
2005-05-28 00:50:30 +02:00
|
|
|
if (pair_to_free)
|
|
|
|
diff_free_filepair(pair_to_free);
|
2005-05-21 11:39:09 +02:00
|
|
|
}
|
2005-05-24 10:10:48 +02:00
|
|
|
diff_debug_queue("done copying original", &outq);
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2005-05-24 10:10:48 +02:00
|
|
|
free(q->queue);
|
|
|
|
*q = outq;
|
|
|
|
diff_debug_queue("done collapsing", q);
|
2005-05-21 11:39:09 +02:00
|
|
|
|
2007-10-25 20:19:10 +02:00
|
|
|
for (i = 0; i < rename_dst_nr; i++)
|
|
|
|
free_filespec(rename_dst[i].two);
|
2005-09-16 01:13:43 +02:00
|
|
|
|
2005-05-24 10:10:48 +02:00
|
|
|
free(rename_dst);
|
|
|
|
rename_dst = NULL;
|
|
|
|
rename_dst_nr = rename_dst_alloc = 0;
|
|
|
|
free(rename_src);
|
|
|
|
rename_src = NULL;
|
|
|
|
rename_src_nr = rename_src_alloc = 0;
|
2005-05-21 11:39:09 +02:00
|
|
|
return;
|
|
|
|
}
|