{"thread":{"id":"16524","subject":"[PATCH v3] bisect: teach \"skip\" to accept a range using \"-r|--range\" option","startedAt":"2008-11-30T06:15:11Z","lastAt":"2008-11-30T08:24:25Z","messageCount":2,"participants":["Christian Couder","Junio C Hamano"],"isPatch":true,"patchVersion":3,"patchTotal":null},"messages":[{"id":"96759","messageId":"20081130071511.e279e8bc.chriscool@tuxfamily.org","threadId":"16524","inReplyTo":null,"subject":"[PATCH v3] bisect: teach \"skip\" to accept a range using \"-r|--range\" option","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-11-30T06:15:11Z","receivedAt":"2008-11-30T06:15:11Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"The current \"git bisect skip\" syntax is \"git bisect skip [<rev>...]\",\nso it's already possible to skip a range of revisions using\nsomething like:\n\n$ git bisect skip $(git rev-list A..B)\n\nwhere A and B are the bounds of the range of commits we want to skip.\nIn this case A itself will not be skipped, but B will be, because\nthat's how \"git rev-list\" works.\n\nThis patch teaches \"git bisect skip\" to accept:\n\n$ git bisect skip --range=A,B\n\nor:\n\n$ git bisect skip -r A,B\n\nto skip the whole range of commits between A included and B included.\n\nBecause we believe that users, in most cases, will want the first\nbound to be skipped too.\n\nIf either A or B is ommited, HEAD will be used instead.\n\nThis is done by expanding each range argument using:\n\ngit rev-list \"${B:-HEAD}\" --not $(git rev-parse \"${A:-HEAD}^@\")\n\nSo the following command:\n\n$ git bisect skip A -r B,C D E --range=F, --range ,G\n\nshould work as expected.\n\nSigned-off-by: Christian Couder <chriscool@tuxfamily.org>\n---\n Documentation/git-bisect.txt |   30 +++++++++++++++++++++++-\n git-bisect.sh                |   52 ++++++++++++++++++++++++++++++++++++++++-\n t/t6030-bisect-porcelain.sh  |   10 +++++++-\n 3 files changed, 88 insertions(+), 4 deletions(-)\n\n\tJunio wrote:\n\t>\n\t> Although I fully realize that the established semantics of A..B in git is\n\t> bottom-exclusive, top-inclusive, and this suggestion breaks the UI\n\t> uniformity by deviating from that convention, I have to wonder if it would\n\t> be more useful if you let the bottom commit (A in your example) also be\n\t> skipped.\n\n\tI agree that it would be perhaps more usefull to skip the bottom commit.\n\tBut in this case I think we should not use the .. notation as it would be\n\tinconsistent. So here is a patch that adds an all inclusive \"-r|--range\"\n\toption.\n\n\tThis patch adds some documentation and a test case too.\n\n\tAfter coming up with this patch, I saw that the previous version has\n\talready been merged into \"next\" and \"master\", but perhaps it can be reverted\n\tand this version applied. Otherwise if the previous version is preferred, I\n\twill come up with another patch to just add some documentation and tests on\n\ttop of the previous version.\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex 39034ec..86f6ad2 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -19,7 +19,7 @@ on the subcommand:\n  git bisect start [<bad> [<good>...]] [--] [<paths>...]\n  git bisect bad [<rev>]\n  git bisect good [<rev>...]\n- git bisect skip [<rev>...]\n+ git bisect skip [(<rev>|<range>)...]\n  git bisect reset [<branch>]\n  git bisect visualize\n  git bisect replay <logfile>\n@@ -164,6 +164,34 @@ But computing the commit to test may be slower afterwards and git may\n eventually not be able to tell the first bad among a bad and one or\n more \"skip\"ped commits.\n \n+You can even skip a range of commits, instead of just one commit,\n+using option -r|--range. For example:\n+\n+------------\n+$ git bisect skip --range=v2.5,v2.6\n+------------\n+\n+or:\n+\n+------------\n+$ git bisect skip -r v2.5,v2.6\n+------------\n+\n+would mean that no commit between versions 2.5 included and 2.6\n+included can be tested.\n+\n+Note that you must take care that the first commit in the given range\n+is an ancestor of the second commit.\n+\n+Also note that if you don't want to skip the first commit of a range\n+you can use something like:\n+\n+------------\n+$ git bisect skip $(git rev-list v2.5..v2.6)\n+------------\n+\n+and the commit pointed to by v2.5 will not be skipped.\n+\n Cutting down bisection by giving more parameters to bisect start\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n \ndiff --git a/git-bisect.sh b/git-bisect.sh\nindex 0d0e278..29a5c2e 100755\n--- a/git-bisect.sh\n+++ b/git-bisect.sh\n@@ -9,7 +9,7 @@ git bisect bad [<rev>]\n         mark <rev> a known-bad revision.\n git bisect good [<rev>...]\n         mark <rev>... known-good revisions.\n-git bisect skip [<rev>...]\n+git bisect skip [(<rev>|<range>)...]\n         mark <rev>... untestable revisions.\n git bisect next\n         find next bisection to test and check it out.\n@@ -191,6 +191,52 @@ check_expected_revs() {\n \tdone\n }\n \n+list_range() {\n+\tcase \"$1\" in\n+\t*,*) ;; # Ok\n+\t*) die \"Bad range: $1\" ;;\n+\tesac\n+\n+\t_A=$(expr \"z$1\" : 'z\\([^,]*\\),.*')\n+\t_B=$(expr \"z$1\" : 'z[^,]*,\\(.*\\)')\n+\n+\t#\n+\t# We want a range with both bounds included.\n+\t# (\"git rev-list ^A B\" would exclude commit A.)\n+\t# This means we want to exclude starting from the parents of _A,\n+\t# not starting from _A itself.\n+\t#\n+\tgit rev-list \"${_B:-HEAD}\" --not $(git rev-parse \"${_A:-HEAD}^@\")\n+}\n+\n+bisect_skip() {\n+        all=''\n+\twhile test $# != 0\n+\tdo\n+\t\tcase \"$1\" in\n+\t\t-r|--range*)\n+\t\t\tcase \"$#,$1\" in\n+\t\t\t*,*=*)\n+\t\t\t\trange=$(expr \"z$1\" : 'z-[^=]*=\\(.*\\)') ;;\n+\t\t\t1,*)\n+\t\t\t\tdie \"Bad or incomplete range: $1\" ;;\n+\t\t\t*)\n+\t\t\t\trange=\"$2\"; shift ;;\n+\t\t\tesac\n+\t\t\trevs=$(list_range \"$range\") ||\n+\t\t\t\tdie \"Bad rev input: $1\"\n+\t\t\t;;\n+\t\t*)\n+\t\t\trevs=\"'$arg'\"\n+\t\t\t;;\n+\t\tesac\n+\t\tshift\n+\t\tall=\"$all $revs\"\n+        done\n+        bisect_state 'skip' $all\n+}\n+\n+\n bisect_state() {\n \tbisect_autostart\n \tstate=$1\n@@ -630,8 +676,10 @@ case \"$#\" in\n         git bisect -h ;;\n     start)\n         bisect_start \"$@\" ;;\n-    bad|good|skip)\n+    bad|good)\n         bisect_state \"$cmd\" \"$@\" ;;\n+    skip)\n+        bisect_skip \"$@\" ;;\n     next)\n         # Not sure we want \"next\" at the UI level anymore.\n         bisect_next \"$@\" ;;\ndiff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh\nindex 85fa39c..e76546c 100755\n--- a/t/t6030-bisect-porcelain.sh\n+++ b/t/t6030-bisect-porcelain.sh\n@@ -313,8 +313,16 @@ test_expect_success 'bisect run & skip: find first bad' '\n \tgrep \"$HASH6 is first bad commit\" my_bisect_log.txt\n '\n \n-test_expect_success 'bisect starting with a detached HEAD' '\n+test_expect_success 'bisect skip range' '\n+\tgit bisect reset &&\n+\tgit bisect start $HASH7 $HASH1 &&\n+\tgit bisect skip --range=$HASH2,$HASH5 &&\n+\ttest \"$HASH6\" = \"$(git rev-parse --verify HEAD)\" &&\n+\ttest_must_fail git bisect bad > my_bisect_log.txt &&\n+\tgrep \"first bad commit could be any of\" my_bisect_log.txt\n+'\n \n+test_expect_success 'bisect starting with a detached HEAD' '\n \tgit bisect reset &&\n \tgit checkout master^ &&\n \tHEAD=$(git rev-parse --verify HEAD) &&\n-- \n1.6.0.4.772.ge8f9a\n"},{"id":"96760","messageId":"7vej0ttydi.fsf@gitster.siamese.dyndns.org","threadId":"16524","inReplyTo":"20081130071511.e279e8bc.chriscool@tuxfamily.org","subject":"Re: [PATCH v3] bisect: teach \"skip\" to accept a range using \"-r|--range\" option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-30T08:24:25Z","receivedAt":"2008-11-30T08:24:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder <chriscool@tuxfamily.org> writes:\n\n> \tJunio wrote:\n> \t>\n> \t> Although I fully realize that the established semantics of A..B in git is\n> \t> bottom-exclusive, top-inclusive, and this suggestion breaks the UI\n> \t> uniformity by deviating from that convention, I have to wonder if it would\n> \t> be more useful if you let the bottom commit (A in your example) also be\n> \t> skipped.\n>\n> \tI agree that it would be perhaps more usefull to skip the bottom commit.\n\nActually I do not think it is such a big deal to warrant more code and\ncomplexity.  \"skip A..B A\", if you really wanted to, would work anyway.\n"}]}