Re: [PATCH] git bisect old/new
- From
Christian Couder <christian.couder@gmail.com>
- Date
- Jun 12, 2012, 05:25 UTC
- Message-ID
- <CAP8UFD1mgKNQRZpuqYgyL__DGpoZ3cOGJC0amoqWT+1Bn_0iTg@mail.gmail.com>
- In-Reply-To
- <1339466625-17461-1-git-send-email-Valentin.Duperray@ensimag.imag.fr>
Hi,
On Tue, Jun 12, 2012 at 4:03 AM, Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> wrote:
Show 26 quoted lines
> When not looking for a regression during a bisect but for a fix or a > change in another given property, it can be confusing to use 'good' > and 'bad'. > This patch introduce `git bisect new` and `git bisect old` as an > alternative to 'bad' and good' : the commits which have the most > recent version of the property must be marked as `new` and the ones > with the older version as `old`. > The output will be the first commit after the change in the property. > During a new/old bisect session you cannot use bad/good commands and > vice-versa. > Some commands are still not available for old/new: > * git bisect start [<new> [<old>...]] is not possible : the > commits will be treated as bad and good. > * git rev-list --bisect does not treat the revs/bisect/new and > revs/bisect/old-SHA1 files. > * thus, git bisect run <cmd> is not available for new/old. > * git bisect visualize seem to work partially : the tags are > displayed correctly but the tree is not limited to the bisect > section. > > Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr> > Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr> > Signed-off-by: Franck Jonas <Franck.Jonas@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>
If you used some design that was discussed on the mailing list or if there have been relevant discussions on the mailing list, it would be nice to have links to the email thread in the commit message.
Show 17 quoted lines
> --- > Documentation/git-bisect.txt | 40 +++++++++++++++ > bisect.c | 88 ++++++++++++++++++++++++--------- > git-bisect.sh | 113 ++++++++++++++++++++++++++++++++--------- > t/t6030-bisect-porcelain.sh | 33 ++++++++++++ > 4 files changed, 226 insertions(+), 48 deletions(-) > > diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt > index e4f46bc..25673c9 100644 > --- a/Documentation/git-bisect.txt > +++ b/Documentation/git-bisect.txt > @@ -20,6 +20,8 @@ on the subcommand: > git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<paths>...] > git bisect bad [<rev>] > git bisect good [<rev>...] > + git bisect new [<rev>] > + git bisect old [<rev>...]
maybe:
git bisect (bad|new) [<rev>] git bisect (good|old) [<rev>...]
Show 12 quoted lines
> git bisect skip [(<rev>|<range>)...] > git bisect reset [<commit>] > git bisect visualize > @@ -104,6 +106,44 @@ For example, `git bisect reset HEAD` will leave you on the current > bisection commit and avoid switching commits at all, while `git bisect > reset bisect/bad` will check out the first bad revision. > > +Alternative research: bisect new and bisect old > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +If you are not looking for a regression but for a change of a given > +property, you can use:
I would rather say:
Alternative terms: bisect new and bisect old ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are not at ease with the terms "bad" and "good", perhaps because you are looking for the commit that introduced a fix, you can alternatively use "new" and "old" instead. But note that you cannot mix "bad" and good" with "new" and "old".
------------------------------------------------ git bisect new [<rev>] ------------------------------------------------
Same as "git bisect bad [<rev>]".
------------------------------------------------ git bisect old [<rev>...] ------------------------------------------------
Same as "git bisect good [<rev>...]".
Show 15 quoted lines
> + > +------------------------------------------------ > +git bisect new [<rev>] > +------------------------------------------------ > + > +Mark the commits that have the new version of the property. > + > +------------------------------------------------ > +git bisect old [<rev>...] > +------------------------------------------------ > + > +Mark the commits that have the old version of the property. > + > +For example, when looking for a fix in the code, the "new" commits are > +the fixed ones and the "old" commits are the unfixed ones.
Please put this in the example section of the doc.
Show 44 quoted lines
> +------------------------------------------------
> +$ git bisect start
> +$ git bisect new # Current version is fixed
> +$ git bisect old bugged_version # bugged_version was the last version
> + # known to be unfixed
> +------------------------------------------------
> +
> +At the end of the commit session, you will have the first commit that
> +have the new version of the property ("fixed" here).
> +
> +You must run `git bisect start` without commits as argument and run
> +`git bisect new <rev>`/`git bisect old <rev>...` after to add the
> +commits.
> +The bisect old/new sessions and the good/bad ones cannot be mixed.
> +You must use `git bisect reset` and start again in order to change
> +the mode.
> +
> Bisect visualize
> ~~~~~~~~~~~~~~~~
>
> diff --git a/bisect.c b/bisect.c
> index 48acf73..474b615 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 *bisect_term_bad;
> +static const char *bisect_term_good;
> +
> /* bits #0-15 in revision.h */
>
> #define COUNTED (1u<<16)
> @@ -403,9 +406,10 @@ 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, bisect_term_bad)) {
> current_bad_sha1 = sha1;
> - } else if (!prefixcmp(refname, "good-")) {
> + } else if (!prefixcmp(refname, "good-") ||
> + !prefixcmp(refname, "old-")) {I don't like very much "good" and "old" to be hardcoded here.
Show 21 quoted lines
> @@ -731,18 +735,25 @@ static void handle_bad_merge_base(void)
> if (is_expected_rev(current_bad_sha1)) {
> char *bad_hex = sha1_to_hex(current_bad_sha1);
> 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(bisect_term_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);
> + } else {
> + fprintf(stderr, "The merge base %s is new.\n"
> + "The property has changed "
> + "between %s and [%s].\n",
> + bad_hex, bad_hex, good_hex);
> + }I don't like very much "new" to be harcoded here too.
Show 13 quoted lines
> > /* > - * "check_merge_bases" checks that merge bases are not "bad". > + * "check_merge_bases" checks that merge bases are not "bad" (resp. "new"). > * > - * - If one is "bad", it means the user assumed something wrong > + * - If one is "bad" (resp. "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" (resp. "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. > */
I am not sure changing the comments is worth it...
Show 7 quoted lines
> @@ -825,7 +836,8 @@ static int check_ancestors(const char *prefix) > > /* > * "check_good_are_ancestors_of_bad" checks that all "good" revs are > - * ancestor of the "bad" rev. > + * ancestor of the "bad" rev. (resp. all "old" revs are ancestor of > + * the "new" rev).
...because we don't change the name of the function anyway.
Show 18 quoted lines
> *
> * If that's not the case, we need to check the merge bases.
> * If a merge base must be tested by the user, its source code will be
> @@ -838,7 +850,7 @@ static void check_good_are_ancestors_of_bad(const char *prefix, int no_checkout)
> int fd;
>
> if (!current_bad_sha1)
> - die("a bad revision is needed");
> + die("a %s revision is needed", bisect_term_bad);
>
> /* Check if file BISECT_ANCESTORS_OK exists. */
> if (!stat(filename, &st) && S_ISREG(st.st_mode))
> @@ -889,6 +901,30 @@ 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.I am not sure saying "it can be bad/good or new/old" adds anything. You could just say: the defaults are "bad"/"good"
Show 11 quoted lines
> + * We read them and stock them to adapt the messages
> + * accordingly.
> + */
> +void read_bisect_terms(void)
> +{
> + struct strbuf str = STRBUF_INIT;
> + const char *filename = git_path("BISECT_TERMS");
> + FILE *fp = fopen(filename, "r");
> +
> + if (!fp)
> + die_errno("Could not open file '%s'", filename);This is not very compatible with older git versions. I know that it's kind of strange to upgrade git in the middle of a bisection but why not just use "bad"/"good" if there is no file?
Show 22 quoted lines
> + strbuf_getline(&str, fp, '\n');
> + bisect_term_bad = strbuf_detach(&str, NULL);
> + strbuf_getline(&str, fp, '\n');
> + bisect_term_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.
> @@ -898,6 +934,8 @@ static void show_diff_tree(const char *prefix, struct commit *commit)
> */
> int bisect_next_all(const char *prefix, int no_checkout)
> {
> + read_bisect_terms();
> +
> struct rev_info revs;
> struct commit_list *tried;
> int reaches = 0, all = 0, nr, steps;We put all declarations at the beginning of functions.
Show 6 quoted lines
> @@ -920,13 +958,14 @@ int bisect_next_all(const char *prefix, int no_checkout)
>
> if (!revs.commits) {
> /*
> - * We should exit here only if the "bad"
> + * We should exit here only if the "bad" (or "new")Again I don't think it's worth changing comments.
Show 18 quoted lines
> diff --git a/git-bisect.sh b/git-bisect.sh > index 99efbe8..152b4f3 100755 > --- a/git-bisect.sh > +++ b/git-bisect.sh > @@ -1,6 +1,6 @@ > #!/bin/sh > > -USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run]' > +USAGE='[help|start|bad|good|skip|next|reset|visualize|replay|log|run|new|old]' > LONG_USAGE='git bisect help > print this long help message. > git bisect start [--no-checkout] [<bad> [<good>...]] [--] [<pathspec>...] > @@ -22,7 +22,15 @@ git bisect replay <logfile> > git bisect log > show bisect log. > git bisect run <cmd>... > - use <cmd>... to automatically bisect. > + use <cmd>... to automatically bisect
Why this change?
Show 7 quoted lines
> + > +When looking for a change in a given property instead of a regression > +you can use > + > +git bisect new [<rev>] > + mark <rev> as not having the property anymore > +git bisect old [<rev>]
It is: [<rev>...]
> + mark <rev>... as having the property
But anyway if possible I'd rather have:
git bisect (bad|new) [<rev>] git bisect (good|old) [<rev>...]
Show 8 quoted lines
> Please use "git help bisect" to get the full man page.' > > @@ -32,6 +40,8 @@ OPTIONS_SPEC= > > _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]' > _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40" > +NEW="bad" > +OLD="good"
Why not BISECT_BAD_TERM/BISECT_GOOD_TERM instead of NEW/OLD? It should be consistent with bisect.c
Show 9 quoted lines
>
> bisect_head()
> {
> @@ -66,7 +76,7 @@ bisect_autostart() {
>
> bisect_start() {
> #
> - # Check for one bad and then some good revisions.
> + # Check for one bad (or new) and then some good (or old) revisions.I don't think it's worth changing the comments.
Show 8 quoted lines
> @@ -184,8 +210,8 @@ bisect_write() {
> rev="$2"
> nolog="$3"
> case "$state" in
> - bad) tag="$state" ;;
> - good|skip) tag="$state"-"$rev" ;;
> + bad|new) tag="$state" ;;
> + good|skip|old) tag="$state"-"$rev" ;;Why not "$BISECT_TERM_BAD" instead of "bad|new" and "$BISECT_TERM_GOOD|skip" instead of "good|skip|old"?
Show 9 quoted lines
> *) die "$(eval_gettext "Bad bisect_write argument: \$state")" ;;
> esac
> git update-ref "refs/bisect/$tag" "$rev" || exit
> @@ -230,12 +256,12 @@ bisect_state() {
> case "$#,$state" in
> 0,*)
> die "$(gettext "Please call 'bisect_state' with at least one argument.")" ;;
> - 1,bad|1,good|1,skip)
> + 1,bad|1,good|1,skip|1,new|1,old)Idem.
Show 6 quoted lines
> rev=$(git rev-parse --verify $(bisect_head)) || > die "$(gettext "Bad rev input: $(bisect_head)")" > bisect_write "$state" "$rev" > check_expected_revs "$rev" ;; > - 2,bad|*,good|*,skip) > + 2,bad|*,good|*,skip|2,new|*,old)
Idem.
Show 10 quoted lines
> shift
> eval=''
> for rev in "$@"
> @@ -246,8 +272,8 @@ bisect_state() {
> done
> eval "$eval"
> check_expected_revs "$@" ;;
> - *,bad)
> - die "$(gettext "'git bisect bad' can take only one argument.")" ;;
> + *,bad|*,new)Idem.
Show 25 quoted lines
> + die "$(gettext "'git bisect $NEW' can take only one argument.")" ;;
> *)
> usage ;;
> esac
> @@ -256,21 +282,21 @@ bisect_state() {
>
> bisect_next_check() {
> missing_good= missing_bad=
> - git show-ref -q --verify refs/bisect/bad || missing_bad=t
> - test -n "$(git for-each-ref "refs/bisect/good-*")" || missing_good=t
> + git show-ref -q --verify refs/bisect/$NEW || missing_bad=t
> + test -n "$(git for-each-ref "refs/bisect/$OLD-*")" || missing_good=t
>
> case "$missing_good,$missing_bad,$1" in
> ,,*)
> - : have both good and bad - ok
> + : have both good and bad or old and new - ok
> ;;
> *,)
> # do not have both but not asked to fail - just report.
> false
> ;;
> - t,,good)
> - # have bad but not good. we could bisect although
> + t,,good|t,,old)Idem.
Thanks, Christian.