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

Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 13, 2022, 16:01 UTC
Message-ID
<xmqqtu7ldmrz.fsf@gitster.g>
In-Reply-To
<220713.865yk1456z.gmgdl@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 11 quoted lines
> I'm not claiming that we always use 129 when we're fed bad options etc.,
> but rather that that's what parse_options() does, so at this point most
> commands do that consistently.
> 	
> 	./git --blah >/dev/null 2>&1; echo $?
> 	129
> 	./git status --blah >/dev/null 2>&1; echo $?
> 	129
>
> But yes, you can find exceptions still, e.g. try that with "git log" and
> it'll return 128.

Yup, that was my understanding as well. We may have existing breakage that we shouldn't be actively imitating when we do not have to.

> Which, I'm not saying should hold this series up, but just that having
> reviewed it for a few iterations I'm not comfortable saying we haven't
> missed something else, and given the nature of the past whack-a-mole
> fixes it looks like you haven't really looked it either.

"We haven't missed" is not something we can comfortably say, ever, aobut a series with any meaningful size. I am not so worried about it, if it is your only worries. Would it make it less likely to have introduced unintended bugs if we find a way to keep using parse-options?

Show 11 quoted lines
> I'm referring to e.g. the thread ending at [3], where I pointed out that
> "git <subcommand> -h" was broken, you apparently tested one of the
> subcommands and concluded it wasn't broken, but clearly not all of them.
>
> Which, I'd be less concerned about if as pointed out in [1] we don't
> have entirte bisect sub-commands that don't have any test coverage at
> all, so whatever coverage we have probably has major gaps.
>
> 1. https://lore.kernel.org/git/220627.86mtdxhnwk.gmgdl@evledraar.gmail.com/
> 2. https://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/
> 3. https://lore.kernel.org/git/220225.86ilt27uln.gmgdl@evledraar.gmail.com/
Previous: Ævar Arnfjörð BjarmasonNext: Ævar Arnfjörð Bjarmason
Message 12 of 17 in “What's cooking in git.git (Jul 2022, #03; Mon, 11)”
  1. Junio C HamanoJul 12, 2022
  2. gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))Glen Choo, Jul 12, 2022
  3. Junio C HamanoJul 13, 2022
  4. Johannes SchindelinJul 14, 2022
  5. Junio C HamanoJul 14, 2022
  6. Philip OakleyJul 12, 2022
  7. Junio C HamanoJul 13, 2022
  8. ac/bitmap-lookup-table (was: Re: What's cooking in git.git (Jul 2022, #03; Mon, 11))Taylor Blau, Jul 12, 2022
  9. Junio C HamanoJul 13, 2022
  10. js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)Johannes Schindelin, Jul 13, 2022
  11. Ævar Arnfjörð BjarmasonJul 13, 2022
  12. Junio C HamanoJul 13, 2022
  13. Ævar Arnfjörð BjarmasonJul 14, 2022
  14. Johannes SchindelinJul 14, 2022
  15. Ævar Arnfjörð BjarmasonJul 14, 2022
  16. Johannes SchindelinAug 16, 2022
  17. Ævar Arnfjörð BjarmasonAug 17, 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.