git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)
Date: Thu, 14 Jul 2022 23:09:53 +0200	[thread overview]
Message-ID: <220714.86mtdb1jmp.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <p8srrprq-s23s-711n-n452-34qr856qso29@tzk.qr>


On Thu, Jul 14 2022, Johannes Schindelin wrote:

> Hi Junio,
>
> On Wed, 13 Jul 2022, Junio C Hamano wrote:
>
>> Æ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

It doesn't, the claim isn't that there's no way to have it return exit
code 129 on *some* invalid usage. In this case we do the "right" thing.

Rather that as noted in [1] there's other cases where we call die() and
should call usage_msg_opt().

Of course both of those would be more useful if the new built-in still
had the parse_options() usage info we could display. I.e. in this case
the conversion to a built-in leaves on the table nice benefits we'd get
for free.

Compare that with e.g. how "git bundle" handles it, note how we get not
only "don't do that", but also how valid usage would look like:
	
	$ git bundle -h
	usage: git bundle create [-q | --quiet | --progress | --all-progress] [--all-progress-implied]
	                         [--version=<version>] <file> <git-rev-list-args>
	   or: git bundle verify [-q | --quiet] <file>
	   or: git bundle fetch [--filter=<spec>] <uri>
	   or: git bundle list-heads <file> [<refname>...]
	   or: git bundle unbundle [--progress] <file> [<refname>...]
	$ git bundle create -h
	usage: git bundle create [-q | --quiet | --progress | --all-progress] [--all-progress-implied]
	                         [--version=<version>] <file> <git-rev-list-args>
	
	    -q, --quiet           do not show progress meter
	    --progress            show progress meter
	    --all-progress        show progress meter during object writing phase
	    --all-progress-implied
	                          similar to --all-progress when progress meter is shown
	    --version <n>         specify bundle format version

1. https://lore.kernel.org/git/220627.86ilolhnnn.gmgdl@evledraar.gmail.com/

  reply	other threads:[~2022-07-14 21:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-12 17:07 What's cooking in git.git (Jul 2022, #03; Mon, 11) Junio C Hamano
2022-07-12 22:19 ` gc/bare-repo-discovery (was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Glen Choo
2022-07-13 16:29   ` Junio C Hamano
2022-07-14 16:17     ` Johannes Schindelin
2022-07-14 18:27       ` Junio C Hamano
2022-07-12 22:29 ` What's cooking in git.git (Jul 2022, #03; Mon, 11) Philip Oakley
2022-07-13 16:31   ` Junio C Hamano
2022-07-12 23:28 ` ac/bitmap-lookup-table (was: Re: What's cooking in git.git (Jul 2022, #03; Mon, 11)) Taylor Blau
2022-07-13 16:42   ` ac/bitmap-lookup-table Junio C Hamano
2022-07-13 11:10 ` js/bisect-in-c, was Re: What's cooking in git.git (Jul 2022, #03; Mon, 11) Johannes Schindelin
2022-07-13 11:18   ` Ævar Arnfjörð Bjarmason
2022-07-13 16:01     ` Junio C Hamano
2022-07-14  0:22       ` Ævar Arnfjörð Bjarmason
2022-07-14 19:35       ` Johannes Schindelin
2022-07-14 21:09         ` Ævar Arnfjörð Bjarmason [this message]
2022-08-16  8:51           ` Johannes Schindelin
2022-08-17  0:49             ` Ævar Arnfjörð Bjarmason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=220714.86mtdb1jmp.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).