summaryrefslogtreecommitdiff
path: root/bisect.c
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2015-10-05 12:30:06 -0700
committerJunio C Hamano <gitster@pobox.com>2015-10-05 12:30:06 -0700
commit22dd6eb31f85afebce81c0687e7532e78a12aa9d (patch)
tree6da85e99fe1149c5c42a82b600f9132e670fc6fd /bisect.c
parentdc5400e11d4cbd41336a8b7b64f69b4e486ed049 (diff)
parent06e6a745064c4f2f827177f6d92f4b9adb018200 (diff)
downloadgit-22dd6eb31f85afebce81c0687e7532e78a12aa9d.tar.gz
Merge branch 'ad/bisect-terms'
The use of 'good/bad' in "git bisect" made it confusing to use when hunting for a state change that is not a regression (e.g. bugfix). The command learned 'old/new' and then allows the end user to say e.g. "bisect start --term-old=fast --term=new=slow" to find a performance regression. Michael's idea to make 'good/bad' more intelligent does have certain attractiveness ($gname/272867), and makes some of the work on this topic a moot point. * ad/bisect-terms: bisect: allow setting any user-specified in 'git bisect start' bisect: add 'git bisect terms' to view the current terms bisect: add the terms old/new bisect: sanity check on terms
Diffstat (limited to 'bisect.c')
-rw-r--r--bisect.c11
1 files changed, 8 insertions, 3 deletions
diff --git a/bisect.c b/bisect.c
index 041a13d093..053d1a2ab9 100644
--- a/bisect.c
+++ b/bisect.c
@@ -730,6 +730,11 @@ static void handle_bad_merge_base(void)
"This means the bug has been fixed "
"between %s and [%s].\n",
bad_hex, bad_hex, good_hex);
+ } else if (!strcmp(term_bad, "new") && !strcmp(term_good, "old")) {
+ fprintf(stderr, "The merge base %s is new.\n"
+ "The property has changed "
+ "between %s and [%s].\n",
+ bad_hex, bad_hex, good_hex);
} else {
fprintf(stderr, "The merge base %s is %s.\n"
"This means the first '%s' commit is "
@@ -762,11 +767,11 @@ static void handle_skipped_merge_base(const unsigned char *mb)
}
/*
- * "check_merge_bases" checks that merge bases are not "bad".
+ * "check_merge_bases" checks that merge bases are not "bad" (or "new").
*
- * - If one is "bad", it means the user assumed something wrong
+ * - If one is "bad" (or "new"), it means the user assumed something wrong
* and we must exit with a non 0 error code.
- * - If one is "good", that's good, we have nothing to do.
+ * - If one is "good" (or "old"), that's good, we have nothing to do.
* - If one is "skipped", we can't know but we should warn.
* - If we don't know, we should check it out and ask the user to test.
*/