threads / patch / 39302

patchbisect: improve output when bad commit is found

Subject: [PATCH] bisect: improve output when bad commit is found

## tl;dr

5 messages between May 11, 2015 and May 12, 2015. Diffs are folded; open one to read it.

replies: 4people: 2as markdown or json

Trevor Saunders· May 11, 2015, 20:58 UTC · lore

When the first bad commit has been found git bisect prints something like this

<40 char sha1> is the first bad commit Commit <40 char sha1> ...

<raw diff output>

The raw diff output is not really useful, and its kind of silly to print the sha1 twice. Instead lets print something like

the first bad commit is Commit <sha1> ...

This also fixes an odd inconsistancy where if the first bad commit is a
trivial merge git bisect will only print the first line.
---
 bisect.c                    |  9 +++------
 git-bisect.sh               |  2 +-
 t/t6030-bisect-porcelain.sh | 30 +++++++++++++++++++-----------
 3 files changed, 23 insertions(+), 18 deletions(-)
Show changes to 3 files +23 −18

bisect.c, git-bisect.sh, t/t6030-bisect-porcelain.sh

diff --git a/bisect.c b/bisect.c
index 10f5e57..a0ebb7f 100644
--- a/bisect.c
+++ b/bisect.c
@@ -875,17 +875,14 @@ static void show_diff_tree(const char *prefix, struct commit *commit)
 	init_revisions(&opt, prefix);
 	git_config(git_diff_basic_config, NULL); /* no "diff" UI options */
 	opt.abbrev = 0;
-	opt.diff = 1;
+	opt.diff = 0;
+	opt.always_show_header = 1;
 
 	/* This is what "--pretty" does */
 	opt.verbose_header = 1;
 	opt.use_terminator = 0;
 	opt.commit_format = CMIT_FMT_DEFAULT;
 
-	/* diff-tree init */
-	if (!opt.diffopt.output_format)
-		opt.diffopt.output_format = DIFF_FORMAT_RAW;
-
 	log_tree_commit(&opt, commit);
 }
 
@@ -942,7 +939,7 @@ int bisect_next_all(const char *prefix, int no_checkout)
 
 	if (!hashcmp(bisect_rev, current_bad_oid->hash)) {
 		exit_if_skipped_commits(tried, current_bad_oid);
-		printf("%s is the first bad commit\n", bisect_rev_hex);
+		puts("the first bad commit is");
 		show_diff_tree(prefix, revs.commits->item);
 		/* This means the bisection process succeeded. */
 		exit(10);
diff --git a/git-bisect.sh b/git-bisect.sh
index ae3fec2..cb4bd2f 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -480,7 +480,7 @@ exit code \$res from '\$command' is < 0 or >= 128" >&2
 			exit $res
 		fi
 
-		if sane_grep "is the first bad commit" "$GIT_DIR/BISECT_RUN" >/dev/null
+		if sane_grep "the first bad commit is" "$GIT_DIR/BISECT_RUN" >/dev/null
 		then
 			gettextln "bisect run success"
 			exit 0;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 06b4868..bf50d20 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -26,6 +26,14 @@ add_line_into_file()
     git commit --quiet -m "$MSG" $_file
 }
 
+check_bisect_msg()
+{
+	file=$1
+	hash=$2
+	grep "the first bad commit is" $file || return $?
+	grep $hash $file || return $?
+}
+
 HASH1=
 HASH2=
 HASH3=
@@ -189,7 +197,7 @@ test_expect_success 'bisect skip: successful result' '
 	git bisect start $HASH4 $HASH1 &&
 	git bisect skip &&
 	git bisect bad > my_bisect_log.txt &&
-	grep "$HASH2 is the first bad commit" my_bisect_log.txt
+	check_bisect_msg my_bisect_log.txt $HASH2
 '
 
 # $HASH1 is good, $HASH4 is bad, we skip $HASH3 and $HASH2
@@ -254,7 +262,7 @@ test_expect_success \
      git bisect good $HASH1 &&
      git bisect bad $HASH4 &&
      git bisect run ./test_script.sh > my_bisect_log.txt &&
-     grep "$HASH3 is the first bad commit" my_bisect_log.txt &&
+     check_bisect_msg my_bisect_log.txt $HASH3 &&
      git bisect reset'
 
 # We want to automatically find the commit that
@@ -267,7 +275,7 @@ test_expect_success \
      chmod +x test_script.sh &&
      git bisect start $HASH4 $HASH1 &&
      git bisect run ./test_script.sh > my_bisect_log.txt &&
-     grep "$HASH4 is the first bad commit" my_bisect_log.txt &&
+     check_bisect_msg my_bisect_log.txt $HASH4 &&
      git bisect reset'
 
 # $HASH1 is good, $HASH5 is bad, we skip $HASH3
@@ -280,14 +288,14 @@ test_expect_success 'bisect skip: add line and then a new test' '
 	git bisect start $HASH5 $HASH1 &&
 	git bisect skip &&
 	git bisect good > my_bisect_log.txt &&
-	grep "$HASH5 is the first bad commit" my_bisect_log.txt &&
+	check_bisect_msg my_bisect_log.txt $HASH5 &&
 	git bisect log > log_to_replay.txt &&
 	git bisect reset
 '
 
 test_expect_success 'bisect skip and bisect replay' '
 	git bisect replay log_to_replay.txt > my_bisect_log.txt &&
-	grep "$HASH5 is the first bad commit" my_bisect_log.txt &&
+	check_bisect_msg my_bisect_log.txt $HASH5 &&
 	git bisect reset
 '
 
@@ -328,7 +336,7 @@ test_expect_success 'bisect run & skip: find first bad' '
 	chmod +x test_script.sh &&
 	git bisect start $HASH7 $HASH1 &&
 	git bisect run ./test_script.sh > my_bisect_log.txt &&
-	grep "$HASH6 is the first bad commit" my_bisect_log.txt
+	check_bisect_msg my_bisect_log.txt $HASH6
 '
 
 test_expect_success 'bisect skip only one range' '
@@ -378,7 +386,7 @@ test_expect_success 'bisect does not create a "bisect" branch' '
 	rev_hash6=$(git rev-parse --verify HEAD) &&
 	test "$rev_hash6" = "$HASH6" &&
 	git bisect good > my_bisect_log.txt &&
-	grep "$HASH7 is the first bad commit" my_bisect_log.txt &&
+	check_bisect_msg my_bisect_log.txt $HASH7 &&
 	git bisect reset &&
 	rev_hash6=$(git rev-parse --verify bisect) &&
 	test "$rev_hash6" = "$HASH6" &&
@@ -527,7 +535,7 @@ test_expect_success 'restricting bisection on one dir' '
 	para1=$(git rev-parse --verify HEAD) &&
 	test "$para1" = "$PARA_HASH1" &&
 	git bisect bad > my_bisect_log.txt &&
-	grep "$PARA_HASH1 is the first bad commit" my_bisect_log.txt
+	check_bisect_msg my_bisect_log.txt $PARA_HASH1
 '
 
 test_expect_success 'restricting bisection on one dir and a file' '
@@ -545,7 +553,7 @@ test_expect_success 'restricting bisection on one dir and a file' '
 	para1=$(git rev-parse --verify HEAD) &&
 	test "$para1" = "$PARA_HASH1" &&
 	git bisect good > my_bisect_log.txt &&
-	grep "$PARA_HASH4 is the first bad commit" my_bisect_log.txt
+	check_bisect_msg my_bisect_log.txt $PARA_HASH4
 '
 
 test_expect_success 'skipping away from skipped commit' '
@@ -576,7 +584,7 @@ test_expect_success 'test bisection on bare repo - --no-checkout specified' '
 			"test \$(git rev-list BISECT_HEAD ^$HASH2 --max-count=1 | wc -l) = 0" \
 			>../nocheckout.log
 	) &&
-	grep "$HASH3 is the first bad commit" nocheckout.log
+	check_bisect_msg  nocheckout.log $HASH3
 '
 
 
@@ -591,7 +599,7 @@ test_expect_success 'test bisection on bare repo - --no-checkout defaulted' '
 			"test \$(git rev-list BISECT_HEAD ^$HASH2 --max-count=1 | wc -l) = 0" \
 			>../defaulted.log
 	) &&
-	grep "$HASH3 is the first bad commit" defaulted.log
+	check_bisect_msg defaulted.log $HASH3
 '
 
 #
-- 
2.4.0.78.g7c6ecbf.dirty
Junio C Hamano· May 11, 2015, 21:12 UTC · re: Trevor Saunders · lore

Re: [PATCH] bisect: improve output when bad commit is found

Trevor Saunders <tbsaunde@tbsaunde.org> writes:
> When the first bad commit has been found git bisect prints something
> like this
Show 8 quoted lines
>
> <40 char sha1> is the first bad commit
> Commit <40 char sha1>
> ...
>
> <raw diff output>
>
> The raw diff output is not really useful, and its kind of silly to print

End "something like this" with a colon, and indent the example display, i.e.

        ... prints something like this:
            <40-hex object name> is the first bad commit
            Commit <40-hex object name>
        The raw diff output is ...
Show 5 quoted lines
> the sha1 twice.  Instead lets print something like
>
> the first bad commit is
> Commit <sha1>
> ...
Likewise.
> This also fixes an odd inconsistancy where if the first bad commit is a
> trivial merge git bisect will only print the first line.
> ---
Sign-off?
> -		printf("%s is the first bad commit\n", bisect_rev_hex);
> +		puts("the first bad commit is");
s/the/The/, I would think.
Show 10 quoted lines
> diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
> index 06b4868..bf50d20 100755
> --- a/t/t6030-bisect-porcelain.sh
> +++ b/t/t6030-bisect-porcelain.sh
> @@ -26,6 +26,14 @@ add_line_into_file()
>      git commit --quiet -m "$MSG" $_file
>  }
>  
> +check_bisect_msg()
> +{
Find this paragraph in Documentation/CodingGuidelines:
 - We prefer a space between the function name and the parentheses,
   and no space inside the parentheses. The opening "{" should also
   be on the same line.
> +	file=$1
> +	hash=$2
> +	grep "the first bad commit is" $file || return $?
> +	grep $hash $file || return $?
Is it OK to have these strings anywhere in the $file?
Thanks.
Trevor Saunders· May 11, 2015, 23:11 UTC · re: Junio C Hamano · lore

Re: [PATCH] bisect: improve output when bad commit is found

On Mon, May 11, 2015 at 02:12:51PM -0700, Junio C Hamano wrote:
Show 6 quoted lines
> Trevor Saunders <tbsaunde@tbsaunde.org> writes:
> > This also fixes an odd inconsistancy where if the first bad commit is a
> > trivial merge git bisect will only print the first line.
> > ---
> 
> Sign-off?
oops, forgot
> > -		printf("%s is the first bad commit\n", bisect_rev_hex);
> > +		puts("the first bad commit is");
> 
> s/the/The/, I would think.
yup
Show 16 quoted lines
> > diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
> > index 06b4868..bf50d20 100755
> > --- a/t/t6030-bisect-porcelain.sh
> > +++ b/t/t6030-bisect-porcelain.sh
> > @@ -26,6 +26,14 @@ add_line_into_file()
> >      git commit --quiet -m "$MSG" $_file
> >  }
> >  
> > +check_bisect_msg()
> > +{
> 
> Find this paragraph in Documentation/CodingGuidelines:
> 
>  - We prefer a space between the function name and the parentheses,
>    and no space inside the parentheses. The opening "{" should also
>    be on the same line.

yeah, I did it that way to be consistant with the near by function add_lineinto_file, but I can change if that's prefered.

Show 6 quoted lines
> > +	file=$1
> > +	hash=$2
> > +	grep "the first bad commit is" $file || return $?
> > +	grep $hash $file || return $?
> 
> Is it OK to have these strings anywhere in the $file?

Its not great, but the test seems to log multiple invokations of git bisect into the same file, so there may be text about previous runs before we are told which commit is bad.

Junio C Hamano· May 12, 2015, 02:08 UTC · re: Trevor Saunders · lore

Re: [PATCH] bisect: improve output when bad commit is found

Trevor Saunders <tbsaunde@tbsaunde.org> writes:
Show 10 quoted lines
>> > +	file=$1
>> > +	hash=$2
>> > +	grep "the first bad commit is" $file || return $?
>> > +	grep $hash $file || return $?
>> 
>> Is it OK to have these strings anywhere in the $file?
>
> Its not great, but the test seems to log multiple invokations of git
> bisect into the same file, so there may be text about previous runs
> before we are told which commit is bad.

So if we had a previous entry that happens to match $hash, even if the current test stopped and pointed at a different thing, this test declares a success?

This function knows how the $file should end, so it might be more sensible to craft the expected output and compare the tail end of the $file with it, something like:

	(
		echo "The first bad commit is"
                git show -s "$hash"
	) >expect &&
        cnt=$(wc -l <expect) &&
        tail -n $cnt "$file" >actual &&
        test_cmp expect actual
perhaps?
Trevor Saunders· May 12, 2015, 02:10 UTC · re: Junio C Hamano · lore

Re: [PATCH] bisect: improve output when bad commit is found

On Mon, May 11, 2015 at 07:08:46PM -0700, Junio C Hamano wrote:
Show 16 quoted lines
> Trevor Saunders <tbsaunde@tbsaunde.org> writes:
> 
> >> > +	file=$1
> >> > +	hash=$2
> >> > +	grep "the first bad commit is" $file || return $?
> >> > +	grep $hash $file || return $?
> >> 
> >> Is it OK to have these strings anywhere in the $file?
> >
> > Its not great, but the test seems to log multiple invokations of git
> > bisect into the same file, so there may be text about previous runs
> > before we are told which commit is bad.
> 
> So if we had a previous entry that happens to match $hash, even if
> the current test stopped and pointed at a different thing, this test
> declares a success?
err yeah, didn't think of that :(
Show 13 quoted lines
> This function knows how the $file should end, so it might be more
> sensible to craft the expected output and compare the tail end of
> the $file with it, something like:
> 
> 	(
> 		echo "The first bad commit is"
>                 git show -s "$hash"
> 	) >expect &&
>         cnt=$(wc -l <expect) &&
>         tail -n $cnt "$file" >actual &&
>         test_cmp expect actual
> 
> perhaps?
seems about right.
Thanks!
Trev

← back to recent threads