Hi,
On Tue, Jun 12, 2012 at 4:03 AM, Valentin Duperray
<Valentin.Duperray@xxxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxxx>
> Signed-off-by: Lucien Kong <Lucien.Kong@xxxxxxxxxxxxxxx>
> Signed-off-by: Franck Jonas <Franck.Jonas@xxxxxxxxxxxxxxx>
> Signed-off-by: Thomas Nguy <Thomas.Nguy@xxxxxxxxxxxxxxx>
> Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@xxxxxxxxxxxxxxx>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx>
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.
> ---
> 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>...]
> 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>...]".
> +
> +------------------------------------------------
> +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.
> +------------------------------------------------
> +$ 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.
> @@ -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.
>
> /*
> - * "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...
> @@ -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.
> *
> * 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"
> + * 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?
> + 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.
> @@ -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.
> 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?
> +
> +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>...]
> 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
>
> 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.
> @@ -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"?
> *) 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.
> 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.
> 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.
> + 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html