All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Antoine Delaite <antoine.delaite@ensimag.grenoble-inp.fr>
Cc: git@vger.kernel.org, remi.lespinet@ensimag.grenoble-inp.fr,
	louis--alexandre.stuber@ensimag.grenoble-inp.fr,
	remi.galan-alfonso@ensimag.grenoble-inp.fr,
	guillaume.pages@ensimag.grenoble-inp.fr,
	Matthieu.Moy@grenoble-inp.fr, chriscool@tuxfamily.org,
	thomasxnguy@gmail.com, valentinduperray@gmail.com
Subject: Re: [PATCH 3/4] bisect: simplify the add of new bisect terms
Date: Mon, 08 Jun 2015 13:42:34 -0700	[thread overview]
Message-ID: <xmqqvbey7wzp.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1433794930-5158-3-git-send-email-antoine.delaite@ensimag.grenoble-inp.fr> (Antoine Delaite's message of "Mon, 8 Jun 2015 22:22:09 +0200")

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?

  reply	other threads:[~2015-06-08 20:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08 20:22 [PATCH 1/4] bisect : correction of typo Antoine Delaite
2015-06-08 20:22 ` [PATCH 2/4] bisect: replace hardcoded "bad|good" by variables Antoine Delaite
2015-06-08 20:30   ` Junio C Hamano
2015-06-09  6:45   ` Matthieu Moy
2015-06-09  8:12     ` Christian Couder
2015-06-09 12:39       ` Matthieu Moy
2015-06-09 19:18     ` Junio C Hamano
2015-06-08 20:22 ` [PATCH 3/4] bisect: simplify the add of new bisect terms Antoine Delaite
2015-06-08 20:42   ` Junio C Hamano [this message]
2015-06-09 18:17     ` Antoine Delaite
2015-06-10 16:30       ` Matthieu Moy
2015-06-09  7:01   ` Matthieu Moy
2015-06-09  8:39     ` Christian Couder
2015-06-09 20:17     ` Louis-Alexandre Stuber
2015-06-10  0:39       ` Junio C Hamano
2015-06-10  7:15         ` Louis-Alexandre Stuber
2015-06-10  8:03           ` Matthieu Moy
2015-06-10  9:41             ` Louis-Alexandre Stuber
2015-06-10 15:24               ` Matthieu Moy
2015-06-10 15:10             ` Junio C Hamano
2015-06-10 15:25               ` Matthieu Moy
2015-06-10 16:11                 ` Junio C Hamano
2015-06-08 20:22 ` [PATCH 4/4] bisect: add the terms old/new Antoine Delaite
2015-06-08 21:21   ` Junio C Hamano
     [not found] <1183699596.323718.1433875699237.JavaMail.zimbra@ensimag.grenoble-inp.fr>
2015-06-10  7:09 ` [PATCH 3/4] bisect: simplify the add of new bisect terms Antoine Delaite

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=xmqqvbey7wzp.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=antoine.delaite@ensimag.grenoble-inp.fr \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=guillaume.pages@ensimag.grenoble-inp.fr \
    --cc=louis--alexandre.stuber@ensimag.grenoble-inp.fr \
    --cc=remi.galan-alfonso@ensimag.grenoble-inp.fr \
    --cc=remi.lespinet@ensimag.grenoble-inp.fr \
    --cc=thomasxnguy@gmail.com \
    --cc=valentinduperray@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.