git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
Date: Tue, 24 Jun 2008 18:09:28 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.1.00.0806241808400.9925@racer> (raw)
In-Reply-To: <alpine.DEB.1.00.0806241750030.9925@racer>


When you look for a fix instead of a regression, it can be quite hard
to twist your brain into choosing the correct bisect command between
'git bisect bad' and 'git bisect good'.

So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Tue, 24 Jun 2008, Johannes Schindelin wrote:

	> Okay, that's 3 people who I take the courage from to turn this 
	> into a proper patch.

	And this is my first attempt at a proper patch for it.

	Now with documentation, and hopefully all places where the
	user is being told about a "bad" commit.

 Documentation/git-bisect.txt |   16 ++++++++++++++++
 git-bisect.sh                |   25 ++++++++++++++++++-------
 2 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 3ca0d33..3fb3b11 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -26,6 +26,9 @@ on the subcommand:
  git bisect log
  git bisect run <cmd>...
 
+ git bisect fixed [<rev>]
+ git bisect unfixed [<rev>...]
+
 This command uses 'git-rev-list --bisect' option to help drive the
 binary search process to find which change introduced a bug, given an
 old "good" commit object name and a later "bad" commit object name.
@@ -76,6 +79,19 @@ bad", and ask for the next bisection.
 Until you have no more left, and you'll have been left with the first
 bad kernel rev in "refs/bisect/bad".
 
+Searching for fixes instead of regressions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sometimes you need to find a fix, not a regression.  The bisection
+machinery is really the same for this, but it might be tricky to remember
+to mark a commit "bad" when it contains the fix.
+
+So synonyms for "bad" and "good" are available, "fixed" and "unfixed"
+respectively.
+
+To mark a commit that contains the fix, call "git bisect fixed", and
+"git bisect unfixed" if it does not contain the fix.
+
 Bisect reset
 ~~~~~~~~~~~~
 
diff --git a/git-bisect.sh b/git-bisect.sh
index 8b11107..6e71e1a 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|fixed|unfixed|skip|next|reset|visualize|replay|log|run]'
 LONG_USAGE='git bisect help
         print this long help message.
 git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
@@ -24,6 +24,13 @@ git bisect log
 git bisect run <cmd>...
         use <cmd>... to automatically bisect.
 
+When not looking for a regression, but a fix instead, you can use
+
+git bisect fixed [<rev>]
+	mark <rev> as having the fix you are looking for
+git bisect unfixed [<rev>]
+	mark <rev> as not having the fix you are looking for
+
 Please use "git help bisect" to get the full man page.'
 
 OPTIONS_SPEC=
@@ -216,7 +223,7 @@ bisect_next_check() {
 	t,,good)
 		# have bad but not good.  we could bisect although
 		# this is less optimum.
-		echo >&2 'Warning: bisecting only with a bad commit.'
+		echo >&2 'Warning: bisecting only with a bad (or fixed) commit.'
 		if test -t 0
 		then
 			printf >&2 'Are you sure [Y/n]? '
@@ -231,7 +238,7 @@ bisect_next_check() {
 			THEN='then '
 		}
 		echo >&2 'You '$THEN'need to give me at least one good' \
-			'and one bad revisions.'
+			'and one bad (or fixed) revision.'
 		echo >&2 '(You can use "git bisect bad" and' \
 			'"git bisect good" for that.)'
 		exit 1 ;;
@@ -324,7 +331,7 @@ exit_if_skipped_commits () {
 	_tried=$1
 	if expr "$_tried" : ".*[|].*" > /dev/null ; then
 		echo "There are only 'skip'ped commit left to test."
-		echo "The first bad commit could be any of:"
+		echo "The first bad (or fixed) commit could be any of:"
 		echo "$_tried" | tr '[|]' '[\012]'
 		echo "We cannot bisect more!"
 		exit 2
@@ -356,7 +363,7 @@ bisect_next() {
 	fi
 	if [ "$bisect_rev" = "$bad" ]; then
 		exit_if_skipped_commits "$bisect_tried"
-		echo "$bisect_rev is first bad commit"
+		echo "$bisect_rev is first bad (or fixed) commit"
 		git diff-tree --pretty $bisect_rev
 		exit 0
 	fi
@@ -474,7 +481,8 @@ bisect_run () {
 
       cat "$GIT_DIR/BISECT_RUN"
 
-      if grep "first bad commit could be any of" "$GIT_DIR/BISECT_RUN" \
+      if grep "first bad (or fixed) commit could be any of" \
+			"$GIT_DIR/BISECT_RUN" \
 		> /dev/null; then
 	  echo >&2 "bisect run cannot continue any more"
 	  exit $res
@@ -486,7 +494,8 @@ bisect_run () {
 	  exit $res
       fi
 
-      if grep "is first bad commit" "$GIT_DIR/BISECT_RUN" > /dev/null; then
+      if grep "is first bad (or fixed) commit" \
+		"$GIT_DIR/BISECT_RUN" > /dev/null; then
 	  echo "bisect run success"
 	  exit 0;
       fi
@@ -501,6 +510,8 @@ case "$#" in
 *)
     cmd="$1"
     shift
+    test $cmd = fixed && cmd=bad
+    test $cmd = unfixed && cmd=good
     case "$cmd" in
     help)
         git bisect -h ;;
-- 
1.5.6.173.gde14c

  reply	other threads:[~2008-06-24 17:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-24 14:17 [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed' Johannes Schindelin
2008-06-24 14:42 ` Stephan Beyer
2008-06-24 14:55   ` Johannes Schindelin
2008-06-24 15:16     ` Stephan Beyer
2008-06-24 15:02 ` Nicolas Pitre
2008-06-24 16:38 ` Jeff King
2008-06-24 16:50   ` Johannes Schindelin
2008-06-24 17:09     ` Johannes Schindelin [this message]
2008-06-24 17:41       ` [NON-TOY " Jeff King
2008-06-24 19:22         ` Daniel Barkalow
2008-06-24 19:26           ` Johannes Schindelin
2008-06-24 22:30         ` Junio C Hamano
2008-06-27 13:48           ` [PATCH, next version] " Johannes Schindelin
2008-06-27 23:03             ` Junio C Hamano
2008-06-28 13:48               ` Johannes Schindelin
2008-06-28 17:52                 ` Junio C Hamano
2008-06-24 19:59       ` [NON-TOY PATCH] " SZEDER Gábor
2008-06-24 20:06       ` Michael Haggerty
2008-06-24 20:38         ` Johannes Schindelin
2008-06-24 22:31           ` Junio C Hamano
2008-06-24 22:43             ` Nicolas Pitre
2008-06-26  6:03             ` Christian Couder
2008-06-24 22:48         ` Lea Wiemann
2008-06-24 23:53           ` A Large Angry SCM
2008-06-25  7:27             ` Karl Hasselström
2008-06-24 16:54   ` [TOY " Reini Urban

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.1.00.0806241808400.9925@racer \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).