Junio C Hamano <gitster@xxxxxxxxx> writes: > For this change, it might look like this: > > The script given to the `git bisect run script` may broken in some > way. [Explain why it is bad that 'script' is not run on the known > bad or good revisions here in the current code. The script is run > to test on the midway commit anyway and the lack of +x bit would > be noticed just as quickly as you retest a known good or bad > revision, so this 'feature' appears as a pure overhead to cause > extra checkouts and builds for no great additional benefit, at > least to me, and I tried but cannot make a good case for you > here]. After thinking about this a bit, I think the reason why you want is because once "bisect run" starts to run, you cannot tell between the script that failed because it itself is buggy and the script that noticed a breakage in the revision being tested. So you may waste a whole night if you start a long bisection session and then leave work after seeing a few first failures. But I still am skeptical if it is worth the overhead of checking out a large working tree to a different revision (like Chromium), only to sanity check the script. If I were in such a situation, what I would do would be to first manually run 'script' outside "git bisect run" on the revision that happens to be checked out (i.e. the one that "git bisect" asked me to test) before throwing the script at "git bisect run". Sure, I won't know if the revision yet to be tested is good or bad, so there is no yardstick to tell if the script is producing an expected result, but didn't I have the same issue when declaring the "current" bad commit was bad and the "current" good commit was good?
