mirror of
https://github.com/git/git
synced 2024-08-24 18:26:02 +00:00
![Linus Torvalds](/assets/img/avatar_default.png)
Ok, so on the kernel list, some people noticed that "git log --follow" doesn't work too well with some files in the x86 merge, because a lot of files got renamed in very special ways. In particular, there was a pattern of doing single commits with renames that looked basically like - rename "filename.h" -> "filename_64.h" - create new "filename.c" that includes "filename_32.h" or "filename_64.h" depending on whether we're 32-bit or 64-bit. which was preparatory for smushing the two trees together. Now, there's two issues here: - "filename.c" *remained*. Yes, it was a rename, but there was a new file created with the old name in the same commit. This was important, because we wanted each commit to compile properly, so that it was bisectable, so splitting the rename into one commit and the "create helper file" into another was *not* an option. So we need to break associations where the contents change too much. Fine. We have the -B flag for that. When we break things up, then the rename detection will be able to figure out whether there are better alternatives. - "git log --follow" didn't with with -B. Now, the second case was really simple: we use a different "diffopt" structure for the rename detection than the basic one (which we use for showing the diffs). So that second case is trivially fixed by a trivial one-liner that just copies the break_opt values from the "real" diffopts to the one used for rename following. So now "git log -B --follow" works fine: diff --git a/tree-diff.c b/tree-diff.c index 26bdbdd..7c261fd 100644 --- a/tree-diff.c +++ b/tree-diff.c @@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co diff_opts.detect_rename = DIFF_DETECT_RENAME; diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT; diff_opts.single_follow = opt->paths[0]; + diff_opts.break_opt = opt->break_opt; paths[0] = NULL; diff_tree_setup_paths(paths, &diff_opts); if (diff_setup_done(&diff_opts) < 0) however, the end result does *not* work. Because our diffcore-break.c logic is totally bogus! In particular: - it used to do if (base_size < MINIMUM_BREAK_SIZE) return 0; /* we do not break too small filepair */ which basically says "don't bother to break small files". But that "base_size" is the *smaller* of the two sizes, which means that if some large file was rewritten into one that just includes another file, we would look at the (small) result, and decide that it's smaller than the break size, so it cannot be worth it to break it up! Even if the other side was ten times bigger and looked *nothing* like the samell file! That's clearly bogus. I replaced "base_size" with "max_size", so that we compare the *bigger* of the filepair with the break size. - It calculated a "merge_score", which was the score needed to merge it back together if nothing else wanted it. But even if it was *so* different that we would never want to merge it back, we wouldn't consider it a break! That makes no sense. So I added if (*merge_score_p > break_score) return 1; to make it clear that if we wouldn't want to merge it at the end, it was *definitely* a break. - It compared the whole "extent of damage", counting all inserts and deletes, but it based this score on the "base_size", and generated the damage score with delta_size = src_removed + literal_added; damage_score = delta_size * MAX_SCORE / base_size; but that makes no sense either, since quite often, this will result in a number that is *bigger* than MAX_SCORE! Why? Because base_size is (again) the smaller of the two files we compare, and when you start out from a small file and add a lot (or start out from a large file and remove a lot), the base_size is going to be much smaller than the damage! Again, the fix was to replace "base_size" with "max_size", at which point the damage actually becomes a sane percentage of the whole. With these changes in place, not only does "git log -B --follow" work for the case that triggered this in the first place, ie now git log -B --follow arch/x86/kernel/vmlinux_64.lds.S actually gives reasonable results. But I also wanted to verify it in general, by doing a full-history git log --stat -B -C on my kernel tree with the old code and the new code. There's some tweaking to be done, but generally, the new code generates much better results wrt breaking up files (and then finding better rename candidates). Here's a few examples of the "--stat" output: - This: include/asm-x86/Kbuild | 2 - include/asm-x86/debugreg.h | 79 +++++++++++++++++++++++++++++++++++------ include/asm-x86/debugreg_32.h | 64 --------------------------------- include/asm-x86/debugreg_64.h | 65 --------------------------------- 4 files changed, 68 insertions(+), 142 deletions(-) Becomes: include/asm-x86/Kbuild | 2 - include/asm-x86/{debugreg_64.h => debugreg.h} | 9 +++- include/asm-x86/debugreg_32.h | 64 ------------------------- 3 files changed, 7 insertions(+), 68 deletions(-) - This: include/asm-x86/bug.h | 41 +++++++++++++++++++++++++++++++++++++++-- include/asm-x86/bug_32.h | 37 ------------------------------------- include/asm-x86/bug_64.h | 34 ---------------------------------- 3 files changed, 39 insertions(+), 73 deletions(-) Becomes include/asm-x86/{bug_64.h => bug.h} | 20 +++++++++++++----- include/asm-x86/bug_32.h | 37 ----------------------------------- 2 files changed, 14 insertions(+), 43 deletions(-) Now, in some other cases, it does actually turn a rename into a real "delete+create" pair, and then the diff is usually bigger, so truth in advertizing: it doesn't always generate a nicer diff. But for what -B was meant for, I think this is a big improvement, and I suspect those cases where it generates a bigger diff are tweakable. So I think this diff fixes a real bug, but we might still want to tweak the default values and perhaps the exact rules for when a break happens. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
290 lines
8.6 KiB
C
290 lines
8.6 KiB
C
/*
|
|
* Copyright (C) 2005 Junio C Hamano
|
|
*/
|
|
#include "cache.h"
|
|
#include "diff.h"
|
|
#include "diffcore.h"
|
|
|
|
static int should_break(struct diff_filespec *src,
|
|
struct diff_filespec *dst,
|
|
int break_score,
|
|
int *merge_score_p)
|
|
{
|
|
/* dst is recorded as a modification of src. Are they so
|
|
* different that we are better off recording this as a pair
|
|
* of delete and create?
|
|
*
|
|
* There are two criteria used in this algorithm. For the
|
|
* purposes of helping later rename/copy, we take both delete
|
|
* and insert into account and estimate the amount of "edit".
|
|
* If the edit is very large, we break this pair so that
|
|
* rename/copy can pick the pieces up to match with other
|
|
* files.
|
|
*
|
|
* On the other hand, we would want to ignore inserts for the
|
|
* pure "complete rewrite" detection. As long as most of the
|
|
* existing contents were removed from the file, it is a
|
|
* complete rewrite, and if sizable chunk from the original
|
|
* still remains in the result, it is not a rewrite. It does
|
|
* not matter how much or how little new material is added to
|
|
* the file.
|
|
*
|
|
* The score we leave for such a broken filepair uses the
|
|
* latter definition so that later clean-up stage can find the
|
|
* pieces that should not have been broken according to the
|
|
* latter definition after rename/copy runs, and merge the
|
|
* broken pair that have a score lower than given criteria
|
|
* back together. The break operation itself happens
|
|
* according to the former definition.
|
|
*
|
|
* The minimum_edit parameter tells us when to break (the
|
|
* amount of "edit" required for us to consider breaking the
|
|
* pair). We leave the amount of deletion in *merge_score_p
|
|
* when we return.
|
|
*
|
|
* The value we return is 1 if we want the pair to be broken,
|
|
* or 0 if we do not.
|
|
*/
|
|
unsigned long delta_size, base_size, max_size;
|
|
unsigned long src_copied, literal_added, src_removed;
|
|
|
|
*merge_score_p = 0; /* assume no deletion --- "do not break"
|
|
* is the default.
|
|
*/
|
|
|
|
if (!S_ISREG(src->mode) || !S_ISREG(dst->mode))
|
|
return 0; /* leave symlink rename alone */
|
|
|
|
if (src->sha1_valid && dst->sha1_valid &&
|
|
!hashcmp(src->sha1, dst->sha1))
|
|
return 0; /* they are the same */
|
|
|
|
if (diff_populate_filespec(src, 0) || diff_populate_filespec(dst, 0))
|
|
return 0; /* error but caught downstream */
|
|
|
|
base_size = ((src->size < dst->size) ? src->size : dst->size);
|
|
max_size = ((src->size > dst->size) ? src->size : dst->size);
|
|
if (max_size < MINIMUM_BREAK_SIZE)
|
|
return 0; /* we do not break too small filepair */
|
|
|
|
if (diffcore_count_changes(src, dst,
|
|
NULL, NULL,
|
|
0,
|
|
&src_copied, &literal_added))
|
|
return 0;
|
|
|
|
/* sanity */
|
|
if (src->size < src_copied)
|
|
src_copied = src->size;
|
|
if (dst->size < literal_added + src_copied) {
|
|
if (src_copied < dst->size)
|
|
literal_added = dst->size - src_copied;
|
|
else
|
|
literal_added = 0;
|
|
}
|
|
src_removed = src->size - src_copied;
|
|
|
|
/* Compute merge-score, which is "how much is removed
|
|
* from the source material". The clean-up stage will
|
|
* merge the surviving pair together if the score is
|
|
* less than the minimum, after rename/copy runs.
|
|
*/
|
|
*merge_score_p = (int)(src_removed * MAX_SCORE / src->size);
|
|
if (*merge_score_p > break_score)
|
|
return 1;
|
|
|
|
/* Extent of damage, which counts both inserts and
|
|
* deletes.
|
|
*/
|
|
delta_size = src_removed + literal_added;
|
|
if (delta_size * MAX_SCORE / max_size < break_score)
|
|
return 0;
|
|
|
|
/* If you removed a lot without adding new material, that is
|
|
* not really a rewrite.
|
|
*/
|
|
if ((src->size * break_score < src_removed * MAX_SCORE) &&
|
|
(literal_added * 20 < src_removed) &&
|
|
(literal_added * 20 < src_copied))
|
|
return 0;
|
|
|
|
return 1;
|
|
}
|
|
|
|
void diffcore_break(int break_score)
|
|
{
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
struct diff_queue_struct outq;
|
|
|
|
/* When the filepair has this much edit (insert and delete),
|
|
* it is first considered to be a rewrite and broken into a
|
|
* create and delete filepair. This is to help breaking a
|
|
* file that had too much new stuff added, possibly from
|
|
* moving contents from another file, so that rename/copy can
|
|
* match it with the other file.
|
|
*
|
|
* int break_score; we reuse incoming parameter for this.
|
|
*/
|
|
|
|
/* After a pair is broken according to break_score and
|
|
* subjected to rename/copy, both of them may survive intact,
|
|
* due to lack of suitable rename/copy peer. Or, the caller
|
|
* may be calling us without using rename/copy. When that
|
|
* happens, we merge the broken pieces back into one
|
|
* modification together if the pair did not have more than
|
|
* this much delete. For this computation, we do not take
|
|
* insert into account at all. If you start from a 100-line
|
|
* file and delete 97 lines of it, it does not matter if you
|
|
* add 27 lines to it to make a new 30-line file or if you add
|
|
* 997 lines to it to make a 1000-line file. Either way what
|
|
* you did was a rewrite of 97%. On the other hand, if you
|
|
* delete 3 lines, keeping 97 lines intact, it does not matter
|
|
* if you add 3 lines to it to make a new 100-line file or if
|
|
* you add 903 lines to it to make a new 1000-line file.
|
|
* Either way you did a lot of additions and not a rewrite.
|
|
* This merge happens to catch the latter case. A merge_score
|
|
* of 80% would be a good default value (a broken pair that
|
|
* has score lower than merge_score will be merged back
|
|
* together).
|
|
*/
|
|
int merge_score;
|
|
int i;
|
|
|
|
/* See comment on DEFAULT_BREAK_SCORE and
|
|
* DEFAULT_MERGE_SCORE in diffcore.h
|
|
*/
|
|
merge_score = (break_score >> 16) & 0xFFFF;
|
|
break_score = (break_score & 0xFFFF);
|
|
|
|
if (!break_score)
|
|
break_score = DEFAULT_BREAK_SCORE;
|
|
if (!merge_score)
|
|
merge_score = DEFAULT_MERGE_SCORE;
|
|
|
|
outq.nr = outq.alloc = 0;
|
|
outq.queue = NULL;
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
struct diff_filepair *p = q->queue[i];
|
|
int score;
|
|
|
|
/* We deal only with in-place edit of non directory.
|
|
* We do not break anything else.
|
|
*/
|
|
if (DIFF_FILE_VALID(p->one) && DIFF_FILE_VALID(p->two) &&
|
|
!S_ISDIR(p->one->mode) && !S_ISDIR(p->two->mode) &&
|
|
!strcmp(p->one->path, p->two->path)) {
|
|
if (should_break(p->one, p->two,
|
|
break_score, &score)) {
|
|
/* Split this into delete and create */
|
|
struct diff_filespec *null_one, *null_two;
|
|
struct diff_filepair *dp;
|
|
|
|
/* Set score to 0 for the pair that
|
|
* needs to be merged back together
|
|
* should they survive rename/copy.
|
|
* Also we do not want to break very
|
|
* small files.
|
|
*/
|
|
if (score < merge_score)
|
|
score = 0;
|
|
|
|
/* deletion of one */
|
|
null_one = alloc_filespec(p->one->path);
|
|
dp = diff_queue(&outq, p->one, null_one);
|
|
dp->score = score;
|
|
dp->broken_pair = 1;
|
|
|
|
/* creation of two */
|
|
null_two = alloc_filespec(p->two->path);
|
|
dp = diff_queue(&outq, null_two, p->two);
|
|
dp->score = score;
|
|
dp->broken_pair = 1;
|
|
|
|
free(p); /* not diff_free_filepair(), we are
|
|
* reusing one and two here.
|
|
*/
|
|
continue;
|
|
}
|
|
}
|
|
diff_q(&outq, p);
|
|
}
|
|
free(q->queue);
|
|
*q = outq;
|
|
|
|
return;
|
|
}
|
|
|
|
static void merge_broken(struct diff_filepair *p,
|
|
struct diff_filepair *pp,
|
|
struct diff_queue_struct *outq)
|
|
{
|
|
/* p and pp are broken pairs we want to merge */
|
|
struct diff_filepair *c = p, *d = pp, *dp;
|
|
if (DIFF_FILE_VALID(p->one)) {
|
|
/* this must be a delete half */
|
|
d = p; c = pp;
|
|
}
|
|
/* Sanity check */
|
|
if (!DIFF_FILE_VALID(d->one))
|
|
die("internal error in merge #1");
|
|
if (DIFF_FILE_VALID(d->two))
|
|
die("internal error in merge #2");
|
|
if (DIFF_FILE_VALID(c->one))
|
|
die("internal error in merge #3");
|
|
if (!DIFF_FILE_VALID(c->two))
|
|
die("internal error in merge #4");
|
|
|
|
dp = diff_queue(outq, d->one, c->two);
|
|
dp->score = p->score;
|
|
diff_free_filespec_data(d->two);
|
|
diff_free_filespec_data(c->one);
|
|
free(d);
|
|
free(c);
|
|
}
|
|
|
|
void diffcore_merge_broken(void)
|
|
{
|
|
struct diff_queue_struct *q = &diff_queued_diff;
|
|
struct diff_queue_struct outq;
|
|
int i, j;
|
|
|
|
outq.nr = outq.alloc = 0;
|
|
outq.queue = NULL;
|
|
|
|
for (i = 0; i < q->nr; i++) {
|
|
struct diff_filepair *p = q->queue[i];
|
|
if (!p)
|
|
/* we already merged this with its peer */
|
|
continue;
|
|
else if (p->broken_pair &&
|
|
!strcmp(p->one->path, p->two->path)) {
|
|
/* If the peer also survived rename/copy, then
|
|
* we merge them back together.
|
|
*/
|
|
for (j = i + 1; j < q->nr; j++) {
|
|
struct diff_filepair *pp = q->queue[j];
|
|
if (pp->broken_pair &&
|
|
!strcmp(pp->one->path, pp->two->path) &&
|
|
!strcmp(p->one->path, pp->two->path)) {
|
|
/* Peer survived. Merge them */
|
|
merge_broken(p, pp, &outq);
|
|
q->queue[j] = NULL;
|
|
break;
|
|
}
|
|
}
|
|
if (q->nr <= j)
|
|
/* The peer did not survive, so we keep
|
|
* it in the output.
|
|
*/
|
|
diff_q(&outq, p);
|
|
}
|
|
else
|
|
diff_q(&outq, p);
|
|
}
|
|
free(q->queue);
|
|
*q = outq;
|
|
|
|
return;
|
|
}
|