git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git bisect bad @

From
René Scharfe <l.s.r@web.de>
Date
Jan 13, 2022, 05:10 UTC
Message-ID
<5be4cdad-6769-68e8-0984-5fe89668d007@web.de>
In-Reply-To
<13e323e9-eb0c-71c3-215f-b77c91fcc4c8@web.de>
Am 12.01.22 um 19:34 schrieb René Scharfe:
Show 41 quoted lines
>
> Am 12.01.22 um 18:50 schrieb Junio C Hamano:
>> René Scharfe <l.s.r@web.de> writes:
>>
>>> It would be nice if we could determine if the command was not found by
>>> the shell and halt the bisection.  This is actually indicated by the
>>> shell using error code 127.  However, the script itself could also exit
>>> with that code (e.g. if one of its commands was not found).  Currently
>>> this is interpreted as a bad revision and bisection continues, as
>>> documented in the man page of git bisect.
>>>
>>> If we'd make error code 127 (and 126) special by stopping the bisection
>>> (like we do for 128 and higher) then scripts that relied on that code
>>> indicating a bad revision would require a manual "git bisect bad" at
>>> each affected step.  Annoying, but not dangerous.  Such a script would
>>> have to be modified to convert codes 126 and 127 to e.g. 1.
>>>
>>> Seems like a reasonable trade-off to me.  Thoughts?
>>
>> Probably.  It is safer than the current "all revisions including the
>> bottom one and the top one are bad" which leads to the "merge-base
>> says your good and bad are nonsense" error for the "command not
>> found" case, but what if the one that reports an error with 127 (or
>> 126) is coming from something other than shell (i.e. the 'bisect
>> run' command was fed is not a script at all)?  Is it a no-no for a
>> random binary that is not an implementation of shell to exit with
>> these error status?
>
> The man page of exit(3) mentions the implementation-defined constants
> EXIT_SUCCESS and EXIT_FAILURE from C99.  It also says: "Cooperating
> processes may use other values".
>
> sysexits(3) on BSD mentions a few others, all below 100
> (https://man.openbsd.org/sysexits.3).  Its BUGS section says:
> "The choice of an appropriate exit value is often ambiguous.".
>
> So exit code values are only very vaguely standardized.  It's very
> possible that there are programs that use 126 or 127 to signal
> something other than "can't execute" or "cannot find command".  Under
> the new rules the bisect run script would have to translate them to
> some lower value.

Reserving 126 and 127 shouldn't cause too much trouble, but there's also a way to avoid it: bisect run could checkout a known-good revision first and abort if the script returns non-zero for any reason, including its non-existence.

René
Previous: René ScharfeNext: Ramkumar Ramachandra
Message 11 of 31 in “git bisect bad @”
  1. Ramkumar RamachandraJan 9, 2022
  2. Junio C HamanoJan 9, 2022
  3. Ramkumar RamachandraJan 9, 2022
  4. bisect: report actual bisect_state() argument on errorRené Scharfe, Jan 10, 2022
  5. Ramkumar RamachandraJan 10, 2022
  6. Junio C HamanoJan 10, 2022
  7. Ramkumar RamachandraJan 10, 2022
  8. René ScharfeJan 12, 2022
  9. Junio C HamanoJan 12, 2022
  10. René ScharfeJan 12, 2022
  11. René ScharfeJan 13, 2022
  12. Ramkumar RamachandraJan 13, 2022
  13. Christian CouderJan 13, 2022
  14. René ScharfeJan 13, 2022
  15. Ramkumar RamachandraJan 13, 2022
  16. René ScharfeJan 14, 2022
  17. Ramkumar RamachandraJan 14, 2022
  18. René ScharfeJan 18, 2022
  19. Junio C HamanoJan 14, 2022
  20. Junio C HamanoJan 13, 2022
  21. 1/4 bisect--helper: report actual bisect_state() argument on errorRené Scharfe, Jan 18, 2022
  22. 2/4 bisect--helper: release strbuf and strvec on run errorRené Scharfe, Jan 18, 2022
  23. 3/4 bisect: document run behavior with exit codes 126 and 127René Scharfe, Jan 18, 2022
  24. 4/4 bisect--helper: double-check run command on exit code 126 and 127René Scharfe, Jan 18, 2022
  25. Junio C HamanoJan 19, 2022
  26. René ScharfeJan 19, 2022
  27. Junio C HamanoFeb 4, 2022
  28. René ScharfeFeb 4, 2022
  29. Ramkumar RamachandraFeb 4, 2022
  30. Junio C HamanoFeb 4, 2022
  31. Ramkumar RamachandraFeb 4, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.