Git development
 help / color / mirror / Atom feed
From: Christian Couder <chriscool@tuxfamily.org>
To: Junio C Hamano <junkio@cox.net>
Cc: "Uwe Kleine-König" <ukleinek@informatik.uni-freiburg.de>,
	git@vger.kernel.org
Subject: Re: [PATCH] Documentation: "bisect run" can be given bangs before the run script.
Date: Sat, 5 May 2007 14:57:03 +0200	[thread overview]
Message-ID: <200705051457.03277.chriscool@tuxfamily.org> (raw)
In-Reply-To: <7vmz0m3261.fsf@assigned-by-dhcp.cox.net>

Hi Junio and Uwe,

Le jeudi 3 mai 2007 07:29, Junio C Hamano a écrit :
> I am not convinced that '!' is a good extension for two and half
> reasons.
>
>  * The expected use is not quite clear.  If it is not used to
>    run a custom test script but something stock as "make", by
>    the nature of UNIX exit status convention, you are looking
>    for the commit that _fixed_ some breakage (i.e. "which commit
>    fixed the compilation error?").  While sometimes that is a
>    useful thing to do, it feels somewhat of limited value.

Well, of course the main expected use is for something like "make" or "grep" 
or "./test_something.sh" where "test_something.sh" is an already existing 
script.

Especially because "git bisect run ! grep foo bar.txt" seems to me like a 
nice way to find the commit that introduced "foo" in "bar.txt" and I have 
been frustrated that it does not work. (Perhaps "git blame" can do it too, 
but I think "git bisect run" should be faster and more specific.)

>    On the other hand, if you are running a custom test script, I
>    do not think it is unreasonable to always require that a test
>    script to signal "bad" with small non-zero, "good" with zero,
>    and error with high non-zero status, as we already do.

I agree this is probably the most usefull use of "git bisect run". But 
sometimes, perhaps for a one shot use, you already have something that 
could work if only you could revert the exist status. I think it is a good 
idea to give user some rope for this case.

>  * How should this interact with the "high non-zero status means
>    an error and we cannot bisect" return convention?

If you use a bare "! grep foobar /*/*" on the command line for example and 
you kill it before it's finished, you will still get a 0 exit code. This 
means that, with the bash "!" keyword, any error gives a "good" result. I 
think it's better to keep this behavior.

If we still wants something that keeps the "high non-zero status means an 
error and we cannot bisect" return convention, then let's call it a "--not" 
option or something like that. I will implement that if you prefer. I can 
even implement both "!" and "--not" if you want.

By the way I think that sometimes it could happens that any exit code other 
than 0 means a "bad" revision and not "we cannot bisect". In this case 
using "git bisect run ! ! my_script" can be usefull. 

>  * I was hoping that we can officially support "don't know,
>    cannot test this one, please give me another" for interactive
>    use, and at the same time allow the run-script used by
>    "git bisect run" to signal such with a special exit value
>    (perhaps "exit 42").  Taken together with the previous point,
>    it is not clear how '!' should interact with such an
>    enhancement.

My bang patch does not in any way prevents from adding such a "don't know, 
cannot test this one, please give me another" improvement. It's just 
another option to make "git bisect run" more convenient in some cases.

Christian (a give them rope proponent).

      parent reply	other threads:[~2007-05-05 16:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-03  5:06 [PATCH] Documentation: "bisect run" can be given bangs before the run script Christian Couder
2007-05-03  5:29 ` Junio C Hamano
2007-05-03  7:03   ` Uwe Kleine-König
2007-05-05 12:57   ` Christian Couder [this message]

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

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

  git send-email \
    --in-reply-to=200705051457.03277.chriscool@tuxfamily.org \
    --to=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=ukleinek@informatik.uni-freiburg.de \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox