Re: [PATCH v8 5/5] bisect: allow any terms set by user
Junio C Hamano gits...@pobox.com writes:
they would call term2 into term1 somewhere. e.g.
-ancestors of term1.
+ancestors of term1. For example, if something was buggy in
+the old part of the history, you know somewhere the bug was
+fixed, and you want to find the exact commit that fixed it,
+you may want to say `git bisect terms fixed broken`; this
+way, you would mark a commit that still has the bug with
+`broken`, and a newer one after the fix with `fixed`.
or something?
Yes.
I am wondering (together with the documentation patch) if it would
be better to be more explicit, instead of term[12], like this:
git bisect terms new old
Yes. I eliminated all instance of term1 and term2 in the doc of the
patch, and replaced with term-old and term-new.
+bisect_terms () {
+case $# in
+0)
+if test -s $GIT_DIR/BISECT_TERMS
+then
+{
+read term1
+read term2
+}$GIT_DIR/BISECT_TERMS
+gettextln Your current terms are $term1 and $term2.
The same comment on this part. Instead of git bisect terms that
just says You are using $term1 and $term2, the users would benefit
if it said You are using $term1 for newer state and $term2 for
older state [*1*].
Done. It's up to date on
https://github.com/moy/git/tree/bisect-terms
Will resend.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 5/5] bisect: allow any terms set by user
From: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
Introduction of the git bisect terms function.
The user can set its own terms.
It will work exactly like before. The terms must be set
before the start.
Signed-off-by: Antoine Delaite antoine.dela...@ensimag.grenoble-inp.fr
Signed-off-by: Louis Stuber stub...@ensimag.grenoble-inp.fr
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
Documentation/git-bisect.txt | 19 +
git-bisect.sh| 68
t/t6030-bisect-porcelain.sh | 43
3 files changed, 125 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 3c3021a..a37336e 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -133,6 +133,25 @@ 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.
+Alternative terms: use your own terms
+~
+
+If the builtins terms bad/good and new/old do not satisfy you, you can
+set your own terms.
+
+
+git bisect terms term1 term2
+
+
+This command has to be used before a bisection has started.
+The term1 must be associated with the latest revisions and term2 with the
+ancestors of term1.
+
+Only the first bisection following the 'git bisect terms' will use the terms.
+If you mistyped one of the terms you can do again 'git bisect terms term1
+term2'.
+
+
Bisect visualize
diff --git a/git-bisect.sh b/git-bisect.sh
index 73763a2..8ef2b94 100644
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[help|start|bad|good|new|old|skip|next|reset|visualize|replay|log|run]'
+USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [--no-checkout] [bad [good...]] [--] [pathspec...]
@@ -11,6 +11,8 @@ git bisect (bad|new) [rev]
git bisect (good|old) [rev...]
mark rev... known-good revisions/
revisions before change in a given property.
+git bisect terms term1 term2
+ set up term1 and term2 as bisection terms.
git bisect skip [(rev|range)...]
mark rev... untestable revisions.
git bisect next
@@ -82,6 +84,14 @@ bisect_start() {
# revision_seen is true if a git bisect start
# has revision as arguments
revision_seen=0
+ # terms_defined is used to detect if the user
+ # defined his own terms with git bisect terms
+ terms_defined=0
+ if test -s $GIT_DIR/TERMS_DEFINED
+ then
+ terms_defined=1
+ get_terms
+ fi
if test z$(git rev-parse --is-bare-repository) != zfalse
then
mode=--no-checkout
@@ -180,10 +190,14 @@ bisect_start() {
}
git rev-parse --sq-quote $@ $GIT_DIR/BISECT_NAMES
eval $eval true
- if test $revision_seen -eq 1 test ! -s $GIT_DIR/BISECT_TERMS
+ if test $revision_seen -eq 1 test ! -s $GIT_DIR/BISECT_TERMS ||
test $terms_defined -eq 1
then
echo $NAME_BAD $GIT_DIR/BISECT_TERMS
- echo $NAME_GOOD $GIT_DIR/BISECT_TERMS
+ echo $NAME_GOOD $GIT_DIR/BISECT_TERMS
+ if test $terms_defined -eq 1
+ then
+ echo git bisect terms $NAME_BAD $NAME_GOOD
$GIT_DIR/BISECT_LOG || exit
+ fi
fi
echo git bisect start$orig_args $GIT_DIR/BISECT_LOG || exit
#
@@ -419,6 +433,7 @@ bisect_clean_state() {
rm -f $GIT_DIR/BISECT_NAMES
rm -f $GIT_DIR/BISECT_RUN
rm -f $GIT_DIR/BISECT_TERMS
+ rm -f $GIT_DIR/TERMS_DEFINED
# 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
@@ -447,6 +462,8 @@ bisect_replay () {
eval $cmd ;;
$NAME_GOOD|$NAME_BAD|skip)
bisect_write $command $rev ;;
+ terms)
+ bisect_terms $rev ;;
*)
die $(gettext ?? what are you talking about?) ;;
esac
@@ -531,7 +548,8 @@ get_terms () {
check_and_set_terms () {
cmd=$1
case $cmd in
- bad|good|new|old)
+ skip|start|terms) ;;
+ *)
if test -s $GIT_DIR/BISECT_TERMS test $cmd !=
$NAME_BAD test $cmd != $NAME_GOOD
then
die $(eval_gettext Invalid command: you're currently
in a \$NAME_BAD/\$NAME_GOOD bisect.)
@@ -564,6 +582,44 @@ bisect_voc () {
esac
}
+bisect_terms () {
+ case $# in
+ 0)
+ if test -s $GIT_DIR/BISECT_TERMS
+ then
Re: [PATCH v8 5/5] bisect: allow any terms set by user
Matthieu Moy matthieu@imag.fr writes:
+Alternative terms: use your own terms
+~
+
+If the builtins terms bad/good and new/old do not satisfy you, you can
+set your own terms.
+
+
+git bisect terms term1 term2
+
+
+This command has to be used before a bisection has started.
+The term1 must be associated with the latest revisions and term2 with the
+ancestors of term1.
While this is not incorrect per-se, it would be more helpful to tell
the readers that they are hunting for a commit that changes the state
they would call term2 into term1 somewhere. e.g.
-ancestors of term1.
+ancestors of term1. For example, if something was buggy in
+the old part of the history, you know somewhere the bug was
+fixed, and you want to find the exact commit that fixed it,
+you may want to say `git bisect terms fixed broken`; this
+way, you would mark a commit that still has the bug with
+`broken`, and a newer one after the fix with `fixed`.
or something?
-USAGE='[help|start|bad|good|new|old|skip|next|reset|visualize|replay|log|run]'
+USAGE='[help|start|bad|good|new|old|terms|skip|next|reset|visualize|replay|log|run]'
LONG_USAGE='git bisect help
print this long help message.
git bisect start [--no-checkout] [bad [good...]] [--] [pathspec...]
@@ -11,6 +11,8 @@ git bisect (bad|new) [rev]
git bisect (good|old) [rev...]
mark rev... known-good revisions/
revisions before change in a given property.
+git bisect terms term1 term2
+ set up term1 and term2 as bisection terms.
This will not help those who cannot remember which one between these
two they want:
git bisect terms new old
git bisect terms old new
I am wondering (together with the documentation patch) if it would
be better to be more explicit, instead of term[12], like this:
git bisect terms new old
or even
git bisect terms bad good
assuming that the only reason they use 'terms' is because they are
sufficiently familiar with 'git bisect' and (intellectually) know
that 'bad' is more recent and 'good' is what it used to be, but have
trouble remembering which one is which during a hunt for a fix.
+bisect_terms () {
+ case $# in
+ 0)
+ if test -s $GIT_DIR/BISECT_TERMS
+ then
+ {
+ read term1
+ read term2
+ }$GIT_DIR/BISECT_TERMS
+ gettextln Your current terms are $term1 and $term2.
The same comment on this part. Instead of git bisect terms that
just says You are using $term1 and $term2, the users would benefit
if it said You are using $term1 for newer state and $term2 for
older state [*1*].
Thanks.
[Footnote]
*1* It is funny that I had to rewrite this if it said... a few
times to make sure I got newer and older right, even though I had
the relevant pieces (and only releavant pieces) of information for
the doc and help text in a single patch form while composing this
response. I suspect that an end user without such material would be
a lot more confused than I was.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
