[PATCH 3/4] bisect: simplify the add of new bisect terms

[PATCH 3/4] bisect: simplify the add of new bisect terms

[Antoine Delaite]

Hi, 

Thanks for the review ! 
(sorry if you received this twice)

Christian Couder <christian.couder@gmail.com> wrote : 

>>> + name_bad = "bad"; 
>>> + name_good = "good"; 
>>> + } else { 
>>> + strbuf_getline(&str, fp, '\n'); 
>>> + name_bad = strbuf_detach(&str, NULL); 
>>> + strbuf_getline(&str, fp, '\n'); 
>>> + name_good = strbuf_detach(&str, NULL); 
>>> + } 
>> 
>> I would have kept just 
>> 
>> name_bad = "bad"; 
>> name_good = "good"; 
>> 
>> in this patch, and introduce BISECT_TERMS in a separate one. 
> 
>Yeah I agree that it is more logical to have first a patch that does 
>on bisect.c the same thing as patch 2 does on git-bisect.sh. 
> 
>For example the patch series could be for now: 
> 
>1) bisect: typo fix 
>2) bisect: replace hardcoded "bad|good" with variables 
>3) git-bisect: replace hardcoded "bad|good" with variables 
>4) bisect: simplify adding new terms 
>5) bisect: add old/new terms 

For now we will keep name_bad and name_good as variables. 
About the patch series shouldn't I squash the commit 2) and 3) into one? 

[PATCH 1/4] bisect : correction of typo

[Antoine Delaite]

---
 bisect.c                    | 2 +-
 t/t6030-bisect-porcelain.sh | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bisect.c b/bisect.c
index 10f5e57..de92953 100644
--- a/bisect.c
+++ b/bisect.c
@@ -743,7 +743,7 @@ static void handle_bad_merge_base(void)
 
 	fprintf(stderr, "Some good revs are not ancestor of the bad rev.\n"
 		"git bisect cannot work properly in this case.\n"
-		"Maybe you mistake good and bad revs?\n");
+		"Maybe you mistook good and bad revs?\n");
 	exit(1);
 }
 
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 06b4868..9e2c203 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -362,7 +362,7 @@ test_expect_success 'bisect starting with a detached HEAD' '
 test_expect_success 'bisect errors out if bad and good are mistaken' '
 	git bisect reset &&
 	test_must_fail git bisect start $HASH2 $HASH4 2> rev_list_error &&
-	grep "mistake good and bad" rev_list_error &&
+	grep "mistook good and bad" rev_list_error &&
 	git bisect reset
 '
 
-- 
2.4.1.414.ge7a9de3.dirty

[PATCH 3/4] bisect: simplify the add of new bisect terms

[Antoine Delaite]

We create a file BISECT_TERMS in the repository .git to be read during a
bisection. The fonctions to be changed if we add new terms are quite
few.
In git-bisect.sh :
	check_and_set_terms
	bisect_voc
In bisect.c :
	handle_bad_merge_base

Signed-off-by: Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr>
Signed-off-by: Louis Stuber <stuberl@ensimag.grenoble-inp.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
---
 bisect.c      | 65 ++++++++++++++++++++++++++++++++++++++++++++---------------
 git-bisect.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 103 insertions(+), 20 deletions(-)

diff --git a/bisect.c b/bisect.c
index de92953..3b7df85 100644
--- a/bisect.c
+++ b/bisect.c
@@ -21,6 +21,9 @@ static const char *argv_checkout[] = {"checkout", "-q", NULL, "--", NULL};
 static const char *argv_show_branch[] = {"show-branch", NULL, NULL};
 static const char *argv_update_ref[] = {"update-ref", "--no-deref", "BISECT_HEAD", NULL, NULL};
 
+static const char *name_bad;
+static const char *name_good;
+
 /* Remember to update object flag allocation in object.h */
 #define COUNTED		(1u<<16)
 
@@ -403,7 +406,7 @@ struct commit_list *find_bisection(struct commit_list *list,
 static int register_ref(const char *refname, const unsigned char *sha1,
 			int flags, void *cb_data)
 {
-	if (!strcmp(refname, "bad")) {
+	if (!strcmp(refname, name_bad)) {
 		current_bad_oid = xmalloc(sizeof(*current_bad_oid));
 		hashcpy(current_bad_oid->hash, sha1);
 	} else if (starts_with(refname, "good-")) {
@@ -634,7 +637,7 @@ static void exit_if_skipped_commits(struct commit_list *tried,
 		return;
 
 	printf("There are only 'skip'ped commits left to test.\n"
-	       "The first bad commit could be any of:\n");
+	       "The first %s commit could be any of:\n", name_bad);
 	print_commit_list(tried, "%s\n", "%s\n");
 	if (bad)
 		printf("%s\n", oid_to_hex(bad));
@@ -732,18 +735,19 @@ static void handle_bad_merge_base(void)
 	if (is_expected_rev(current_bad_oid)) {
 		char *bad_hex = oid_to_hex(current_bad_oid);
 		char *good_hex = join_sha1_array_hex(&good_revs, ' ');
-
-		fprintf(stderr, "The merge base %s is bad.\n"
-			"This means the bug has been fixed "
-			"between %s and [%s].\n",
-			bad_hex, bad_hex, good_hex);
-
+		if (!strcmp(name_bad, "bad")) {
+			fprintf(stderr, "The merge base %s is bad.\n"
+				"This means the bug has been fixed "
+				"between %s and [%s].\n",
+				bad_hex, bad_hex, good_hex);
+		}
 		exit(3);
 	}
 
-	fprintf(stderr, "Some good revs are not ancestor of the bad rev.\n"
+	fprintf(stderr, "Some %s revs are not ancestor of the %s rev.\n"
 		"git bisect cannot work properly in this case.\n"
-		"Maybe you mistook good and bad revs?\n");
+		"Maybe you mistook %s and %s revs?\n",
+		name_good, name_bad, name_good, name_bad);
 	exit(1);
 }
 
@@ -755,10 +759,10 @@ static void handle_skipped_merge_base(const unsigned char *mb)
 
 	warning("the merge base between %s and [%s] "
 		"must be skipped.\n"
-		"So we cannot be sure the first bad commit is "
+		"So we cannot be sure the first %s commit is "
 		"between %s and %s.\n"
 		"We continue anyway.",
-		bad_hex, good_hex, mb_hex, bad_hex);
+		bad_hex, good_hex, name_bad, mb_hex, bad_hex);
 	free(good_hex);
 }
 
@@ -839,7 +843,7 @@ static void check_good_are_ancestors_of_bad(const char *prefix, int no_checkout)
 	int fd;
 
 	if (!current_bad_oid)
-		die("a bad revision is needed");
+		die("a %s revision is needed", name_bad);
 
 	/* Check if file BISECT_ANCESTORS_OK exists. */
 	if (!stat(filename, &st) && S_ISREG(st.st_mode))
@@ -890,6 +894,31 @@ static void show_diff_tree(const char *prefix, struct commit *commit)
 }
 
 /*
+ * The terms used for this bisect session are stocked in
+ * BISECT_TERMS: it can be bad/good or new/old.
+ * We read them and stock them to adapt the messages
+ * accordingly. Default is bad/good.
+ */
+void read_bisect_terms(void)
+{
+	struct strbuf str = STRBUF_INIT;
+	const char *filename = git_path("BISECT_TERMS");
+	FILE *fp = fopen(filename, "r");
+
+	if (!fp) {
+		name_bad = "bad";
+		name_good = "good";
+	} else {
+		strbuf_getline(&str, fp, '\n');
+		name_bad = strbuf_detach(&str, NULL);
+		strbuf_getline(&str, fp, '\n');
+		name_good = strbuf_detach(&str, NULL);
+	}
+	strbuf_release(&str);
+	fclose(fp);
+}
+
+/*
  * We use the convention that exiting with an exit code 10 means that
  * the bisection process finished successfully.
  * In this case the calling shell script should exit 0.
@@ -905,6 +934,7 @@ int bisect_next_all(const char *prefix, int no_checkout)
 	const unsigned char *bisect_rev;
 	char bisect_rev_hex[GIT_SHA1_HEXSZ + 1];
 
+	read_bisect_terms();
 	if (read_bisect_refs())
 		die("reading bisect refs failed");
 
@@ -926,8 +956,10 @@ int bisect_next_all(const char *prefix, int no_checkout)
 		 */
 		exit_if_skipped_commits(tried, NULL);
 
-		printf("%s was both good and bad\n",
-		       oid_to_hex(current_bad_oid));
+		printf("%s was both %s and %s\n",
+		       oid_to_hex(current_bad_oid),
+		       name_good,
+		       name_bad);
 		exit(1);
 	}
 
@@ -942,7 +974,8 @@ 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);
+		printf("%s is the first %s commit\n", bisect_rev_hex,
+			name_bad);
 		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 1f16aaf..529bb43 100644
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -77,6 +77,7 @@ bisect_start() {
 	orig_args=$(git rev-parse --sq-quote "$@")
 	bad_seen=0
 	eval=''
+	start_bad_good=0
 	if test "z$(git rev-parse --is-bare-repository)" != zfalse
 	then
 		mode=--no-checkout
@@ -101,6 +102,9 @@ bisect_start() {
 				die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
 				break
 			}
+
+			start_bad_good=1
+
 			case $bad_seen in
 			0) state='bad' ; bad_seen=1 ;;
 			*) state='good' ;;
@@ -172,6 +176,11 @@ bisect_start() {
 	} &&
 	git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES" &&
 	eval "$eval true" &&
+	if test $start_bad_good -eq 1 -a ! -s "$GIT_DIR/BISECT_TERMS"
+	then
+		echo "$NAME_BAD" >"$GIT_DIR/BISECT_TERMS" &&
+		echo "$NAME_GOOD" >>"$GIT_DIR/BISECT_TERMS"
+	fi &&
 	echo "git bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG" || exit
 	#
 	# Check if we can proceed to the next bisect state.
@@ -232,6 +241,7 @@ bisect_skip() {
 bisect_state() {
 	bisect_autostart
 	state=$1
+	check_and_set_terms $state
 	case "$#,$state" in
 	0,*)
 		die "$(gettext "Please call 'bisect_state' with at least one argument.")" ;;
@@ -294,12 +304,12 @@ bisect_next_check() {
 
 		if test -s "$GIT_DIR/BISECT_START"
 		then
-			gettextln "You need to give me at least one good and one bad revision.
-(You can use \"git bisect bad\" and \"git bisect good\" for that.)" >&2
+			gettextln "You need to give me at least one $(bisect_voc bad) and one $(bisect_voc good) revision.
+(You can use \"git bisect $(bisect_voc bad)\" and \"git bisect $(bisect_voc good)\" for that.)" >&2
 		else
 			gettextln "You need to start by \"git bisect start\".
-You then need to give me at least one good and one bad revision.
-(You can use \"git bisect bad\" and \"git bisect good\" for that.)" >&2
+You then need to give me at least one $(bisect_voc good) and one $(bisect_voc bad) revision.
+(You can use \"git bisect $(bisect_voc bad)\" and \"git bisect $(bisect_voc good)\" for that.)" >&2
 		fi
 		exit 1 ;;
 	esac
@@ -402,6 +412,7 @@ bisect_clean_state() {
 	rm -f "$GIT_DIR/BISECT_LOG" &&
 	rm -f "$GIT_DIR/BISECT_NAMES" &&
 	rm -f "$GIT_DIR/BISECT_RUN" &&
+	rm -f "$GIT_DIR/BISECT_TERMS" &&
 	# Cleanup head-name if it got left by an old version of git-bisect
 	rm -f "$GIT_DIR/head-name" &&
 	git update-ref -d --no-deref BISECT_HEAD &&
@@ -422,6 +433,8 @@ bisect_replay () {
 			rev="$command"
 			command="$bisect"
 		fi
+		get_terms
+		check_and_set_terms "$command"
 		case "$command" in
 		start)
 			cmd="bisect_start $rev"
@@ -499,11 +512,48 @@ bisect_log () {
 	cat "$GIT_DIR/BISECT_LOG"
 }
 
+get_terms () {
+	if test -s "$GIT_DIR/BISECT_TERMS"
+	then
+		NAME_BAD="$(sed -n 1p "$GIT_DIR/BISECT_TERMS")"
+		NAME_GOOD="$(sed -n 2p "$GIT_DIR/BISECT_TERMS")"
+	fi
+}
+
+check_and_set_terms () {
+	cmd="$1"
+	case "$cmd" in
+	bad|good)
+		if test -s "$GIT_DIR/BISECT_TERMS" -a "$cmd" != "$NAME_BAD" -a "$cmd" != "$NAME_GOOD"
+		then
+			die "$(eval_gettext "Invalid command : you're currently in a \$NAME_BAD/\$NAME_GOOD bisect.")"
+		fi
+		case "$cmd" in
+		bad|good)
+			if test ! -s "$GIT_DIR/BISECT_TERMS"
+			then
+				echo "bad" >"$GIT_DIR/BISECT_TERMS" &&
+				echo "good" >>"$GIT_DIR/BISECT_TERMS"
+			fi
+			NAME_BAD="bad"
+			NAME_GOOD="good" ;;
+		esac ;;
+	esac
+}
+
+bisect_voc () {
+	case "$1" in
+	bad) echo "bad" ;;
+	good) echo "good" ;;
+	esac
+}
+
 case "$#" in
 0)
 	usage ;;
 *)
 	cmd="$1"
+	get_terms
 	shift
 	case "$cmd" in
 	help)
-- 
2.4.1.414.ge7a9de3.dirty

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Junio C Hamano]

Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr> writes:

> We create a file BISECT_TERMS in the repository .git to be read during a
> bisection. The fonctions to be changed if we add new terms are quite
> few.
> In git-bisect.sh :
> 	check_and_set_terms
> 	bisect_voc
> In bisect.c :
> 	handle_bad_merge_base
>
> Signed-off-by: Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr>
> Signed-off-by: Louis Stuber <stuberl@ensimag.grenoble-inp.fr>
> Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
> Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
> Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
> Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
> ---

This step seems very straight-forward and makes sense from a cursory
look.

>  /*
> + * The terms used for this bisect session are stocked in
> + * BISECT_TERMS: it can be bad/good or new/old.
> + * We read them and stock them to adapt the messages
> + * accordingly. Default is bad/good.
> + */

s/stock/store/ perhaps?  I think the idea is not to have this file
in the default case so that absence of it would mean you would be
looking for a transition from (older) good to (more recent) bad.

> +void read_bisect_terms(void)
> +{
> +	struct strbuf str = STRBUF_INIT;
> +	const char *filename = git_path("BISECT_TERMS");
> +	FILE *fp = fopen(filename, "r");
> +
> +	if (!fp) {

We might want to see why fopen() failed here.  If it is because the
file did not exist, great.  But otherwise?

> diff --git a/git-bisect.sh b/git-bisect.sh
> index 1f16aaf..529bb43 100644
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -77,6 +77,7 @@ bisect_start() {
>  	orig_args=$(git rev-parse --sq-quote "$@")
>  	bad_seen=0
>  	eval=''
> +	start_bad_good=0
>  	if test "z$(git rev-parse --is-bare-repository)" != zfalse
>  	then
>  		mode=--no-checkout
> @@ -101,6 +102,9 @@ bisect_start() {
>  				die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
>  				break
>  			}
> +
> +			start_bad_good=1
> +

It is unclear what this variable means, or what it means to have
zero or one as its value.

>  			case $bad_seen in
>  			0) state='bad' ; bad_seen=1 ;;
>  			*) state='good' ;;
> @@ -172,6 +176,11 @@ bisect_start() {
>  	} &&
>  	git rev-parse --sq-quote "$@" >"$GIT_DIR/BISECT_NAMES" &&
>  	eval "$eval true" &&
> +	if test $start_bad_good -eq 1 -a ! -s "$GIT_DIR/BISECT_TERMS"

Avoid "test <condition1> -a <condition2>" (or "-o").

> +get_terms () {
> +	if test -s "$GIT_DIR/BISECT_TERMS"
> +	then
> +		NAME_BAD="$(sed -n 1p "$GIT_DIR/BISECT_TERMS")"
> +		NAME_GOOD="$(sed -n 2p "$GIT_DIR/BISECT_TERMS")"

It is sad that we need to open the file twice.  Can't we do
something using "read" perhaps?

Don't we want to make sure these two names are sensible?  We do not
want an empty-string, for example.  I suspect you do not want to
take anything that check-ref-format does not like.

Same comment applies to the C code.

> +bisect_voc () {
> +	case "$1" in
> +	bad) echo "bad" ;;
> +	good) echo "good" ;;
> +	esac
> +}

What is voc?

What if "$1" is neither bad/good?

Did you mean to translate 'bad' to $NAME_BAD and 'good' to $NAME_GOOD?

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Antoine Delaite]

Hi,

Thanks for the review,

Junio C Hamano <gitster@pobox.com> writes:

>>  /*
>> + * The terms used for this bisect session are stocked in
>> + * BISECT_TERMS: it can be bad/good or new/old.
>> + * We read them and stock them to adapt the messages
>> + * accordingly. Default is bad/good.
>> + */
>
>s/stock/store/ perhaps?  I think the idea is not to have this file
>in the default case so that absence of it would mean you would be
>looking for a transition from (older) good to (more recent) bad.

Yes it is nice but a bisect_terms file is a very useful tool for 
verifications at a little cost. For instance, if the user type this:
git bisect start 
git bisect bad HEAD
git bisect old HEAD~10

We created the bisect_terms file after the bad then the error is
directly detected when the user type git bisect old.
And I think having we should limit the impact of this good/bad
default case as we would prefer old/new.

>> +void read_bisect_terms(void)
>> +{
>> +        struct strbuf str = STRBUF_INIT;
>> +        const char *filename = git_path("BISECT_TERMS");
>> +        FILE *fp = fopen(filename, "r");
>> +
>> +        if (!fp) {
>
>We might want to see why fopen() failed here.  If it is because the
>file did not exist, great.  But otherwise?

Should we display a specific message and cancel the last command?

>> diff --git a/git-bisect.sh b/git-bisect.sh
>> index 1f16aaf..529bb43 100644
>> --- a/git-bisect.sh
>> +++ b/git-bisect.sh
>> @@ -77,6 +77,7 @@ bisect_start() {
>>          orig_args=$(git rev-parse --sq-quote "$@")
>>          bad_seen=0
>>          eval=''
>> +        start_bad_good=0
>>          if test "z$(git rev-parse --is-bare-repository)" != zfalse
>>          then
>>                  mode=--no-checkout
>> @@ -101,6 +102,9 @@ bisect_start() {
>>                                  die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
>>                                  break
>>                          }
>> +
>> +                        start_bad_good=1
>> +
>
>It is unclear what this variable means, or what it means to have
>zero or one as its value.

This has been done by our elders and we kept because it was 
useful. We are however trying to remove it. It is in case of 
a 'git bisect start bad_rev good_rev', our function that creates
the bisect_terms is not called. Thus we need to do it manually
in the code.

>> +get_terms () {
>> +        if test -s "$GIT_DIR/BISECT_TERMS"
>> +        then
>> +                NAME_BAD="$(sed -n 1p "$GIT_DIR/BISECT_TERMS")"
>> +                NAME_GOOD="$(sed -n 2p "$GIT_DIR/BISECT_TERMS")"
>
>It is sad that we need to open the file twice.  Can't we do
>something using "read" perhaps?

The cost of it is quite low and we see directly what we meant. We didn't 
found a pretty way to read two lines with read.

>Don't we want to make sure these two names are sensible?  We do not
>want an empty-string, for example.  I suspect you do not want to
>take anything that check-ref-format does not like.
>
>Same comment applies to the C code.

Yes, for now only bad/good/old/new are allowed. But in the future
it will be necessary.

>> +bisect_voc () {
>> +        case "$1" in
>> +        bad) echo "bad" ;;
>> +        good) echo "good" ;;
>> +        esac
>> +}
>
>What is voc?
>
>What if "$1" is neither bad/good?
>
>Did you mean to translate 'bad' to $NAME_BAD and 'good' to $NAME_GOOD?

voc stands for vocabulary. 
This fonction is mainly used after to display all the builtins possibility.  It
is only called internally and if the argument is bad it returns the synonyms of
bad (bad|new in the next patch). 

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Matthieu Moy]

Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr> writes:

>>> +get_terms () {
>>> +        if test -s "$GIT_DIR/BISECT_TERMS"
>>> +        then
>>> +                NAME_BAD="$(sed -n 1p "$GIT_DIR/BISECT_TERMS")"
>>> +                NAME_GOOD="$(sed -n 2p "$GIT_DIR/BISECT_TERMS")"
>>
>>It is sad that we need to open the file twice.  Can't we do
>>something using "read" perhaps?
>
> The cost of it is quite low and we see directly what we meant. We didn't 
> found a pretty way to read two lines with read.

Should be stg like:

{
	read good
	read bad
} <"$GIT_DIR/BISECT_TERMS"

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Matthieu Moy]

> Subject: Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

s/add/addition/

Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr> writes:

> +static const char *name_bad;
> +static const char *name_good;

Same remark as PATCH 2.

>  	} else if (starts_with(refname, "good-")) {

Did you forget this one?

> -
> -		fprintf(stderr, "The merge base %s is bad.\n"
> -			"This means the bug has been fixed "
> -			"between %s and [%s].\n",
> -			bad_hex, bad_hex, good_hex);
> -
> +		if (!strcmp(name_bad, "bad")) {
> +			fprintf(stderr, "The merge base %s is bad.\n"
> +				"This means the bug has been fixed "
> +				"between %s and [%s].\n",
> +				bad_hex, bad_hex, good_hex);
> +		}

You need an "else" here. Maybe it comes later, but as a reviewer, I want
to check that you did not forget it now (because I don't trust myself to
remember that it must be added later).

> @@ -890,6 +894,31 @@ static void show_diff_tree(const char *prefix, struct commit *commit)
>  }
>  
>  /*
> + * The terms used for this bisect session are stocked in
> + * BISECT_TERMS: it can be bad/good or new/old.
> + * We read them and stock them to adapt the messages

s/stock/store/ (two instances)

> + * accordingly. Default is bad/good.
> + */
> +void read_bisect_terms(void)
> +{
> +	struct strbuf str = STRBUF_INIT;
> +	const char *filename = git_path("BISECT_TERMS");
> +	FILE *fp = fopen(filename, "r");
> +
> +	if (!fp) {

I think you would want to error out if errno is not ENOENT.

> +		name_bad = "bad";
> +		name_good = "good";
> +	} else {
> +		strbuf_getline(&str, fp, '\n');
> +		name_bad = strbuf_detach(&str, NULL);
> +		strbuf_getline(&str, fp, '\n');
> +		name_good = strbuf_detach(&str, NULL);
> +	}

I would have kept just

	name_bad = "bad";
	name_good = "good";

in this patch, and introduce BISECT_TERMS in a separate one.

> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -77,6 +77,7 @@ bisect_start() {
>  	orig_args=$(git rev-parse --sq-quote "$@")
>  	bad_seen=0
>  	eval=''
> +	start_bad_good=0
>  	if test "z$(git rev-parse --is-bare-repository)" != zfalse
>  	then
>  		mode=--no-checkout
> @@ -101,6 +102,9 @@ bisect_start() {
>  				die "$(eval_gettext "'\$arg' does not appear to be a valid revision")"
>  				break
>  			}
> +
> +			start_bad_good=1
> +

Why do you need this variable? It seems to me that you are hardcoding
once more that terms can be either "good/bad" or "old/new", which you
tried to eliminate from the previous round.

> +	if test $start_bad_good -eq 1 -a ! -s "$GIT_DIR/BISECT_TERMS"

Avoid test -a (not strictly POSIX, and sometimes ambiguous). Use

test ... && test ...

instead.

> +	then
> +		echo "$NAME_BAD" >"$GIT_DIR/BISECT_TERMS" &&
> +		echo "$NAME_GOOD" >>"$GIT_DIR/BISECT_TERMS"
> +	fi &&

Why not do this unconditionnally? Whether terms are good/bad or old/new,
you can write them to BISECT_TERMS.

> -			gettextln "You need to give me at least one good and one bad revision.
> -(You can use \"git bisect bad\" and \"git bisect good\" for that.)" >&2
> +			gettextln "You need to give me at least one $(bisect_voc bad) and one $(bisect_voc good) revision.
> +(You can use \"git bisect $(bisect_voc bad)\" and \"git bisect $(bisect_voc good)\" for that.)" >&2

I suspect you broke the i18n here too.

> +get_terms () {
> +	if test -s "$GIT_DIR/BISECT_TERMS"
> +	then
> +		NAME_BAD="$(sed -n 1p "$GIT_DIR/BISECT_TERMS")"
> +		NAME_GOOD="$(sed -n 2p "$GIT_DIR/BISECT_TERMS")"
> +	fi
> +}
> +
> +check_and_set_terms () {
> +	cmd="$1"
> +	case "$cmd" in
> +	bad|good)
> +		if test -s "$GIT_DIR/BISECT_TERMS" -a "$cmd" != "$NAME_BAD" -a "$cmd" != "$NAME_GOOD"
> +		then
> +			die "$(eval_gettext "Invalid command : you're currently in a \$NAME_BAD/\$NAME_GOOD bisect.")"

No space before :

> +		fi
> +		case "$cmd" in
> +		bad|good)
> +			if test ! -s "$GIT_DIR/BISECT_TERMS"
> +			then
> +				echo "bad" >"$GIT_DIR/BISECT_TERMS" &&
> +				echo "good" >>"$GIT_DIR/BISECT_TERMS"
> +			fi
> +			NAME_BAD="bad"
> +			NAME_GOOD="good" ;;
> +		esac ;;
> +	esac
> +}
> +
> +bisect_voc () {
> +	case "$1" in
> +	bad) echo "bad" ;;
> +	good) echo "good" ;;
> +	esac
> +}

It's weird to have these hardcoded "bad"/"good" when you already have
BISECT_TERMS in the same patch.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Christian Couder]

On Tue, Jun 9, 2015 at 9:01 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
>> Subject: Re: [PATCH 3/4] bisect: simplify the add of new bisect terms
>
> s/add/addition/
>
> Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr> writes:
>
>> +static const char *name_bad;
>> +static const char *name_good;
>
> Same remark as PATCH 2.

As for patch 2, I think "name_bad" and "name_good" are better than
"name_new" and "name_old".

[...]

>> +             name_bad = "bad";
>> +             name_good = "good";
>> +     } else {
>> +             strbuf_getline(&str, fp, '\n');
>> +             name_bad = strbuf_detach(&str, NULL);
>> +             strbuf_getline(&str, fp, '\n');
>> +             name_good = strbuf_detach(&str, NULL);
>> +     }
>
> I would have kept just
>
>         name_bad = "bad";
>         name_good = "good";
>
> in this patch, and introduce BISECT_TERMS in a separate one.

Yeah I agree that it is more logical to have first a patch that does
on bisect.c the same thing as patch 2 does on git-bisect.sh.

For example the patch series could be for now:

1) bisect: typo fix
2) bisect: replace hardcoded "bad|good" with variables
3) git-bisect: replace hardcoded "bad|good" with variables
4) bisect: simplify adding new terms
5) bisect: add old/new terms

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Louis-Alexandre Stuber]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

> I think you would want to error out if errno is not ENOENT.


Junio C Hamano <jch2355@gmail.com> wrote:

> We might want to see why fopen() failed here. If it is because the
> file did not exist, great. But otherwise?


This file is always supposed to exist when the function is called
unless the user has manually deleted it (or a bug in our programs).

Maybe we should just return an error if the file cannot be opened,
regardless the reason. We kept it like it is, with the default case,
because it was what our elders did, and that aborting because of
BISECT_TERMS is not good for backward compatibility.

But then, in both cases, there is no reason to differenciate ENOENT.
Is that right ?

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Junio C Hamano]

Louis-Alexandre Stuber <stuberl@ensimag.grenoble-inp.fr> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>
>> I think you would want to error out if errno is not ENOENT.
>
>
> Junio C Hamano <jch2355@gmail.com> wrote:
>
>> We might want to see why fopen() failed here. If it is because the
>> file did not exist, great. But otherwise?
>
>
> This file is always supposed to exist when the function is called
> unless the user has manually deleted it (or a bug in our programs).
>
> Maybe we should just return an error if the file cannot be opened,
> regardless the reason. We kept it like it is, with the default case,
> because it was what our elders did, and that aborting because of
> BISECT_TERMS is not good for backward compatibility.
>
> But then, in both cases, there is no reason to differenciate ENOENT.
> Is that right ?

One thing that immediately comes to mind is when you (perhaps
accidentally, or perhaps you were asked to) cd into somebody else's
repository and take a look or help, the file exists but cannot be
read by you and you get EPERM.

That is very different from ENOENT, which is an expected error when
you are not using a customized terms.

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Louis-Alexandre Stuber]

> That is very different from ENOENT, which is an expected error when
> you are not using a customized terms.

But in the current state, we are going to create bisect_terms even if
the bisection is in bad/good mode. Should we differentiate the erors
then ? and should we abort the bisection instead of doing it in
bad/good mode by default ?

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Matthieu Moy]

Louis-Alexandre Stuber <stuberl@ensimag.grenoble-inp.fr> writes:

>> That is very different from ENOENT, which is an expected error when
>> you are not using a customized terms.
>
> But in the current state, we are going to create bisect_terms even if
> the bisection is in bad/good mode.

Which means that in normal cases, you'll either succeed to open it, or
get ENOENT. We're talking about unexcepted cases (you don't have
permission to read it because it's not your file, because you messed up
with a chmod, or whatever reason).

I don't expect a tool to consider that an unreadable file is equivalent
to no file at all. If something's wrong, as a user, I expect a helpful
message telling me what's wrong, to give me a clue on how to solve it.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Louis-Alexandre Stuber]

But ENOENT is not a normal case at all. Should we not treat it the same
way as other fopen() errors ? (either going on with default case or
returning an error)

Would :

>	if (!fp) {
>			die("could not read file '%s': %s",
>				filename, strerror(errno));
>	} else {

be ok ?

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Matthieu Moy]

Louis-Alexandre Stuber <stuberl@ensimag.grenoble-inp.fr> writes:

> But ENOENT is not a normal case at all. Should we not treat it the same
> way as other fopen() errors ? (either going on with default case or
> returning an error)
>
> Would :
>
>>	if (!fp) {
>>			die("could not read file '%s': %s",
>>				filename, strerror(errno));
>>	} else {
>
> be ok ?

That would be much better than what we had in the patch, which did not
look like an error at all:

+	FILE *fp = fopen(filename, "r");
+
+	if (!fp) {
+		name_bad = "bad";
+		name_good = "good";

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Louis-Alexandre Stuber <stuberl@ensimag.grenoble-inp.fr> writes:
>
>>> That is very different from ENOENT, which is an expected error when
>>> you are not using a customized terms.
>>
>> But in the current state, we are going to create bisect_terms even if
>> the bisection is in bad/good mode.
>
> Which means that in normal cases, you'll either succeed to open it, or
> get ENOENT. We're talking about unexcepted cases (you don't have
> permission to read it because it's not your file, because you messed up
> with a chmod, or whatever reason).

I think both I and you misunderstood what they wanted to do, which
is to write out good and bad into terms file even though these are
not customized, and then always read from terms file to learn what
words are used for good and bad.

So from _that_ point of view, ENOENT is an error just like others.

But I do not think it is a good idea to penalize the normal case by
writing the terms file and reading them back from it when the user
is bisecting with good/bad in the first place, so....

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Louis-Alexandre Stuber <stuberl@ensimag.grenoble-inp.fr> writes:
>>
>>>> That is very different from ENOENT, which is an expected error when
>>>> you are not using a customized terms.
>>>
>>> But in the current state, we are going to create bisect_terms even if
>>> the bisection is in bad/good mode.
>>
>> Which means that in normal cases, you'll either succeed to open it, or
>> get ENOENT. We're talking about unexcepted cases (you don't have
>> permission to read it because it's not your file, because you messed up
>> with a chmod, or whatever reason).
>
> I think both I and you misunderstood what they wanted to do, which
> is to write out good and bad into terms file even though these are
> not customized, and then always read from terms file to learn what
> words are used for good and bad.

Yes, indeed.

> But I do not think it is a good idea to penalize the normal case by
> writing the terms file and reading them back from it when the user
> is bisecting with good/bad in the first place, so....

No strong opinion on that, but creating one file doesn't cost much, and
one advantage of writing it unconditionally is that it unifies bad/good
and old/new more in the code. Just the creation of BISECT_TERMS becomes
a special-case.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH 3/4] bisect: simplify the add of new bisect terms

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> But I do not think it is a good idea to penalize the normal case by
>> writing the terms file and reading them back from it when the user
>> is bisecting with good/bad in the first place, so....
>
> No strong opinion on that, but creating one file doesn't cost much, and
> one advantage of writing it unconditionally is that it unifies bad/good
> and old/new more in the code. Just the creation of BISECT_TERMS becomes
> a special-case.

You have to handle that case anyway when I start bisection, which is
going to take very long and I had to leave for the day to come back
the next day to continue, and during the night the sysadmin updates
the installed version of Git.