{"thread":{"id":"7951","subject":"[PATCH] Documentation: \"bisect run\" can be given bangs before the run script.","startedAt":"2007-05-03T05:06:07Z","lastAt":"2007-05-05T12:57:03Z","messageCount":4,"participants":["Christian Couder","Junio C Hamano","Uwe Kleine-König"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"40936","messageId":"20070503070607.fa2ffe92.chriscool@tuxfamily.org","threadId":"7951","inReplyTo":null,"subject":"[PATCH] Documentation: \"bisect run\" can be given bangs before the run script.","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2007-05-03T05:06:07Z","receivedAt":"2007-05-03T05:06:07Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Signed-off-by: Christian Couder <chriscool@tuxfamily.org>\n---\n\nHi Uwe and Junio,\n\nThis is the documentation related to my latest patch:\n\n[RFC/PATCH] Bisect: add special treatment for bangs passed to \"bisect run\".\n\n(http://article.gmane.org/gmane.comp.version-control.git/45943)\n\nThanks in advance,\nChristian.\n\n Documentation/git-bisect.txt |    6 ++++++\n 1 files changed, 6 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt\nindex 5f68ee1..a1cceb5 100644\n--- a/Documentation/git-bisect.txt\n+++ b/Documentation/git-bisect.txt\n@@ -175,6 +175,12 @@ Any other exit code will abort the automatic bisect process. (A\n program that does \"exit(-1)\" leaves $? = 255, see exit(3) manual page,\n the value is chopped with \"& 0377\".)\n \n+You can use one or more \"!\" argument immediately after \"git bisect\n+run\" if you want to revert once or more times the \"run\" script exit\n+code, even if your current shell does not support the \"!\"\n+keyword. Reverting the exit code means 0 gives 1 and anything other\n+than 0 gives 0.\n+\n You may often find that during bisect you want to have near-constant\n tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or\n \"revision that does not have this commit needs this patch applied to\n-- \n1.5.2.rc0.71.g4342-dirty\n"},{"id":"40939","messageId":"7vmz0m3261.fsf@assigned-by-dhcp.cox.net","threadId":"7951","inReplyTo":"20070503070607.fa2ffe92.chriscool@tuxfamily.org","subject":"Re: [PATCH] Documentation: \"bisect run\" can be given bangs before the run script.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-03T05:29:42Z","receivedAt":"2007-05-03T05:29:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I am not convinced that '!' is a good extension for two and half\nreasons.\n\n * The expected use is not quite clear.  If it is not used to\n   run a custom test script but something stock as \"make\", by\n   the nature of UNIX exit status convention, you are looking\n   for the commit that _fixed_ some breakage (i.e. \"which commit\n   fixed the compilation error?\").  While sometimes that is a\n   useful thing to do, it feels somewhat of limited value.\n\n   On the other hand, if you are running a custom test script, I\n   do not think it is unreasonable to always require that a test\n   script to signal \"bad\" with small non-zero, \"good\" with zero,\n   and error with high non-zero status, as we already do.\n\n * How should this interact with the \"high non-zero status means\n   an error and we cannot bisect\" return convention?\n\n * I was hoping that we can officially support \"don't know,\n   cannot test this one, please give me another\" for interactive\n   use, and at the same time allow the run-script used by\n   \"git bisect run\" to signal such with a special exit value\n   (perhaps \"exit 42\").  Taken together with the previous point,\n   it is not clear how '!' should interact with such an\n   enhancement.\n"},{"id":"40947","messageId":"20070503070302.GA4491@informatik.uni-freiburg.de","threadId":"7951","inReplyTo":"7vmz0m3261.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: \"bisect run\" can be given bangs before the run script.","fromName":"Uwe Kleine-König","fromEmail":"ukleinek@informatik.uni-freiburg.de","sentAt":"2007-05-03T07:03:02Z","receivedAt":"2007-05-03T07:03:02Z","isPatch":true,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"Hello,\n\nJunio C Hamano wrote:\n> I am not convinced that '!' is a good extension for two and half\n> reasons.\n> \n>  * The expected use is not quite clear.  If it is not used to\n>    run a custom test script but something stock as \"make\", by\n>    the nature of UNIX exit status convention, you are looking\n>    for the commit that _fixed_ some breakage (i.e. \"which commit\n>    fixed the compilation error?\").  While sometimes that is a\n>    useful thing to do, it feels somewhat of limited value.\n> \n>    On the other hand, if you are running a custom test script, I\n>    do not think it is unreasonable to always require that a test\n>    script to signal \"bad\" with small non-zero, \"good\" with zero,\n>    and error with high non-zero status, as we already do.\n> \n>  * How should this interact with the \"high non-zero status means\n>    an error and we cannot bisect\" return convention?\n> \n>  * I was hoping that we can officially support \"don't know,\n>    cannot test this one, please give me another\" for interactive\n>    use, and at the same time allow the run-script used by\n>    \"git bisect run\" to signal such with a special exit value\n>    (perhaps \"exit 42\").  Taken together with the previous point,\n>    it is not clear how '!' should interact with such an\n>    enhancement.\nAck for all 2½ reasons.\n\nUwe\n\n-- \nUwe Kleine-König\n\nhttp://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2\n"},{"id":"41140","messageId":"200705051457.03277.chriscool@tuxfamily.org","threadId":"7951","inReplyTo":"7vmz0m3261.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: \"bisect run\" can be given bangs before the run script.","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2007-05-05T12:57:03Z","receivedAt":"2007-05-05T12:57:03Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Junio and Uwe,\n\nLe jeudi 3 mai 2007 07:29, Junio C Hamano a écrit :\n> I am not convinced that '!' is a good extension for two and half\n> reasons.\n>\n>  * The expected use is not quite clear.  If it is not used to\n>    run a custom test script but something stock as \"make\", by\n>    the nature of UNIX exit status convention, you are looking\n>    for the commit that _fixed_ some breakage (i.e. \"which commit\n>    fixed the compilation error?\").  While sometimes that is a\n>    useful thing to do, it feels somewhat of limited value.\n\nWell, of course the main expected use is for something like \"make\" or \"grep\" \nor \"./test_something.sh\" where \"test_something.sh\" is an already existing \nscript.\n\nEspecially because \"git bisect run ! grep foo bar.txt\" seems to me like a \nnice way to find the commit that introduced \"foo\" in \"bar.txt\" and I have \nbeen frustrated that it does not work. (Perhaps \"git blame\" can do it too, \nbut I think \"git bisect run\" should be faster and more specific.)\n\n>    On the other hand, if you are running a custom test script, I\n>    do not think it is unreasonable to always require that a test\n>    script to signal \"bad\" with small non-zero, \"good\" with zero,\n>    and error with high non-zero status, as we already do.\n\nI agree this is probably the most usefull use of \"git bisect run\". But \nsometimes, perhaps for a one shot use, you already have something that \ncould work if only you could revert the exist status. I think it is a good \nidea to give user some rope for this case.\n\n>  * How should this interact with the \"high non-zero status means\n>    an error and we cannot bisect\" return convention?\n\nIf you use a bare \"! grep foobar /*/*\" on the command line for example and \nyou kill it before it's finished, you will still get a 0 exit code. This \nmeans that, with the bash \"!\" keyword, any error gives a \"good\" result. I \nthink it's better to keep this behavior.\n\nIf we still wants something that keeps the \"high non-zero status means an \nerror and we cannot bisect\" return convention, then let's call it a \"--not\" \noption or something like that. I will implement that if you prefer. I can \neven implement both \"!\" and \"--not\" if you want.\n\nBy the way I think that sometimes it could happens that any exit code other \nthan 0 means a \"bad\" revision and not \"we cannot bisect\". In this case \nusing \"git bisect run ! ! my_script\" can be usefull. \n\n>  * I was hoping that we can officially support \"don't know,\n>    cannot test this one, please give me another\" for interactive\n>    use, and at the same time allow the run-script used by\n>    \"git bisect run\" to signal such with a special exit value\n>    (perhaps \"exit 42\").  Taken together with the previous point,\n>    it is not clear how '!' should interact with such an\n>    enhancement.\n\nMy bang patch does not in any way prevents from adding such a \"don't know, \ncannot test this one, please give me another\" improvement. It's just \nanother option to make \"git bisect run\" more convenient in some cases.\n\nChristian (a give them rope proponent).\n"}]}