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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 14, 2022, 19:35 UTC
Message-ID: <p8srrprq-s23s-711n-n452-34qr856qso29@tzk.qr>
In-Reply-To: <xmqqtu7ldmrz.fsf@gitster.g>

Hi Junio,

On Wed, 13 Jul 2022, Junio C Hamano wrote:

Show 17 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
> > 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.

This patch series already implements `git bisect` in the desired way:

	$ ./git bisect --invalid; echo $?
	usage: git bisect [help|start|bad|good|new|old|terms|skip|next|reset|visualize|view|replay|log|run]
	129

Ciao, Johannes