Thanks for your answer. I was expecting the HEAD to point to the first bad commit. In mercurial, the exit status tells you information about the bisection process: https://www.mercurial-scm.org/repo/hg/help/bisect Sure one can parse stdout, it's just more tedious than just checking the return code and having the HEAD left to the original bad commit. Pedro. On Thu, Jun 13, 2019 at 11:22 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Pedro Larroy <pedro.larroy.lists@xxxxxxxxx> writes: > > > I'm using git bisect, and for complex reasons I can't use git bisect > > run to drive the bisection. I don't think git bisect bad/good is > > returning a different status code when the first bad commit is found > > and this would be very useful to stop the driver of the bisection. > > > > What do you think? Would such a change be acceptable? > > Probably not. > > A non-zero exit code would indicate that "git bisect" had trouble > finding the next commit to check after being told 'good' (or 'bad'), > which you wouldn't be able to tell from your "first bad one is > found". > > The 'first bad one' is not necessarily the HEAD when the bisect > procedure finds it, so you'd have to read and parse "x is the first > such commit" message anyway, no? And once you start parsing the > message from 'git bisect', you should be able to tell between > "please try this one, you have approximately 7 steps left" and "we > found the first bad one, which is X", without relying on the exit > status, no? >
