git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Martin Langhoff <martin.langhoff@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: [PATCH 1/4] merge: improve inexact rename limit warning
Date: Sat, 19 Feb 2011 05:20:51 -0500	[thread overview]
Message-ID: <20110219102051.GA22508@sigill.intra.peff.net> (raw)
In-Reply-To: <20110219101936.GB20577@sigill.intra.peff.net>

The warning is generated deep in the diffcore code, which
means that it will come first, followed possibly by a spew
of conflicts, making it hard to see.

Instead, let's have diffcore pass back the information about
how big the rename limit would needed to have been, and then
the caller can provide a more appropriate message (and at a
more appropriate time).

No refactoring of other non-merge callers is necessary,
because nobody else was even using the warn_on_rename_limit
feature.

Signed-off-by: Jeff King <peff@peff.net>
---
 diff.h            |    2 +-
 diffcore-rename.c |    5 +++--
 merge-recursive.c |   10 +++++++++-
 merge-recursive.h |    1 +
 4 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/diff.h b/diff.h
index 0083d92..f774c9a 100644
--- a/diff.h
+++ b/diff.h
@@ -110,7 +110,7 @@ struct diff_options {
 	int pickaxe_opts;
 	int rename_score;
 	int rename_limit;
-	int warn_on_too_large_rename;
+	int needed_rename_limit;
 	int dirstat_percent;
 	int setup;
 	int abbrev;
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 0cd4c13..1d3d5cd 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -518,12 +518,13 @@ void diffcore_rename(struct diff_options *options)
 	 * but handles the potential overflow case specially (and we
 	 * assume at least 32-bit integers)
 	 */
+	options->needed_rename_limit = 0;
 	if (rename_limit <= 0 || rename_limit > 32767)
 		rename_limit = 32767;
 	if ((num_create > rename_limit && num_src > rename_limit) ||
 	    (num_create * num_src > rename_limit * rename_limit)) {
-		if (options->warn_on_too_large_rename)
-			warning("too many files (created: %d deleted: %d), skipping inexact rename detection", num_create, num_src);
+		options->needed_rename_limit =
+			num_src > num_create ? num_src : num_create;
 		goto cleanup;
 	}
 
diff --git a/merge-recursive.c b/merge-recursive.c
index 16c2dbe..2ecd456 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -22,6 +22,11 @@
 #include "dir.h"
 #include "submodule.h"
 
+static const char rename_limit_advice[] =
+"inexact rename detection was skipped because there were too many\n"
+"  files. You may want to set your merge.renamelimit variable to at least\n"
+"  %d and retry this merge.";
+
 static struct tree *shift_tree_object(struct tree *one, struct tree *two,
 				      const char *subtree_shift)
 {
@@ -436,12 +441,13 @@ static struct string_list *get_renames(struct merge_options *o,
 			    o->diff_rename_limit >= 0 ? o->diff_rename_limit :
 			    500;
 	opts.rename_score = o->rename_score;
-	opts.warn_on_too_large_rename = 1;
 	opts.output_format = DIFF_FORMAT_NO_OUTPUT;
 	if (diff_setup_done(&opts) < 0)
 		die("diff setup failed");
 	diff_tree_sha1(o_tree->object.sha1, tree->object.sha1, "", &opts);
 	diffcore_std(&opts);
+	if (opts.needed_rename_limit > o->needed_rename_limit)
+		o->needed_rename_limit = opts.needed_rename_limit;
 	for (i = 0; i < diff_queued_diff.nr; ++i) {
 		struct string_list_item *item;
 		struct rename *re;
@@ -1666,6 +1672,8 @@ int merge_recursive(struct merge_options *o,
 		commit_list_insert(h2, &(*result)->parents->next);
 	}
 	flush_output(o);
+	if (o->needed_rename_limit)
+		warning(rename_limit_advice, o->needed_rename_limit);
 	return clean;
 }
 
diff --git a/merge-recursive.h b/merge-recursive.h
index 981ed6a..1a113e2 100644
--- a/merge-recursive.h
+++ b/merge-recursive.h
@@ -20,6 +20,7 @@ struct merge_options {
 	int diff_rename_limit;
 	int merge_rename_limit;
 	int rename_score;
+	int needed_rename_limit;
 	int call_depth;
 	struct strbuf obuf;
 	struct string_list current_file_set;
-- 
1.7.4.1.26.g5e991

  reply	other threads:[~2011-02-19 10:21 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-18 18:58 Merging limitations after directory renames -- interesting test repo Martin Langhoff
2011-02-18 22:21 ` Jeff King
2011-02-18 23:27   ` Linus Torvalds
2011-02-19  0:26     ` Linus Torvalds
2011-02-19  0:52       ` Junio C Hamano
2011-02-19  1:03         ` Linus Torvalds
2011-02-19  1:20           ` Linus Torvalds
2011-02-19  0:55       ` Linus Torvalds
2011-02-19  0:44     ` Junio C Hamano
2011-02-19  9:08     ` Jeff King
2011-02-19 10:19     ` Jeff King
2011-02-19 10:20       ` Jeff King [this message]
2011-02-21 23:33         ` [PATCH 1/4] merge: improve inexact rename limit warning Junio C Hamano
2011-02-22 15:39           ` Jeff King
2011-02-22 18:46             ` Junio C Hamano
2011-02-23  8:02               ` Jeff King
2011-02-19 10:21       ` [PATCH 2/4] bump rename limit defaults (again) Jeff King
2011-02-19 17:54         ` Piotr Krukowiecki
2011-02-20 10:10           ` Jeff King
2011-02-19 20:12         ` Ævar Arnfjörð Bjarmason
2011-02-20 10:12           ` Jeff King
2011-02-19 10:21       ` [PATCH 3/4] commit: stop setting rename limit Jeff King
2011-02-19 10:25       ` [RFC/PATCH 4/4] inexact rename detection eye candy Jeff King
2011-02-19 15:57         ` Linus Torvalds
2011-02-20  9:48           ` Jeff King
2011-02-20  9:51             ` [PATCH 1/3] add inexact rename detection progress infrastructure Jeff King
2011-02-20  9:53             ` [PATCH 2/3] merge: enable progress reporting for rename detection Jeff King
2011-02-20  9:56             ` [PATCH 3/3] pull: propagate --progress to merge Jeff King
2011-02-20 10:37             ` [RFC/PATCH 4/4] inexact rename detection eye candy Jeff King
2011-02-19 16:29         ` Martin Langhoff
2011-02-20 10:04           ` Jeff King
2011-02-20 13:16             ` Martin Langhoff
2011-02-19 15:22       ` Merging limitations after directory renames -- interesting test repo Martin Langhoff
2011-02-19 15:31         ` Martin Langhoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110219102051.GA22508@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.langhoff@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).