From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [Leftoverbits] exit code clean-up?
Date: Thu, 17 Aug 2023 11:24:26 +0200 [thread overview]
Message-ID: <ZN3nSsGOHMDQZ438@ugly> (raw)
In-Reply-To: <xmqqsf8iex5v.fsf_-_@gitster.g>
On Wed, Aug 16, 2023 at 10:04:28AM -0700, Junio C Hamano wrote:
>"git help git" does not have "EXIT CODES" section, and it is assumed
>that the "common sense" of older generation [...] that exiting with 0
>is success and non-zero is failure is shared among its users, which
>might not be warranted these days.
>
well, that's actually a standard (exit(3) has things to say about it),
and given how shell scripts treat exit codes, there is no wiggle room
here. just about every shell intro tutorial explains it.
>We could either
>
> * Be more prescriptive and add "EXIT CODES" section to each and
> every document to describe how we fail in the current code.
>
>or
>
> * Describe "In general, 0 is success, non-zero is failure, but some
> commands may signal more than that with its non-zero exit codes"
> in "git help git", and add "EXIT CODES" section to the manual
> page of the commands whose exit codes matter (there are a
> handful, like "git diff --exit-code" that explicitly says "1" is
> the signal that it found difference as opposed to it failing).
>
i'd go with the second, with some minor modifications:
- 1 is the by far most common non-zero error code (and it matches
EXIT_FAILURE on all relevant systems), so it's ok to state that. it
may be wise to actually check that commands don't deviate from it
needlessly.
- the canonical name of the section appears to be "EXIT STATUS"
regards
prev parent reply other threads:[~2023-08-17 9:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-10 14:40 [PATCH] upload-pack: fix race condition in error messages Derrick Stolee via GitGitGadget
2023-08-10 16:14 ` Junio C Hamano
2023-08-16 6:06 ` [PATCH] upload-pack: fix exit code when denying fetch of unreachable object ID Patrick Steinhardt
2023-08-16 16:16 ` Junio C Hamano
2023-08-16 16:44 ` Junio C Hamano
[not found] ` <CABQH79pick0c1UVc+W8n2QtVmSJAjqXcJGtYSm0aahAFDNvE1g@mail.gmail.com>
2023-08-17 5:12 ` Junio C Hamano
2023-08-17 10:07 ` Patrick Steinhardt
2023-08-17 5:27 ` Jeff King
2023-08-16 17:04 ` [Leftoverbits] exit code clean-up? Junio C Hamano
2023-08-17 5:36 ` Jeff King
2023-08-17 16:03 ` Junio C Hamano
2023-08-17 9:24 ` Oswald Buddenhagen [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZN3nSsGOHMDQZ438@ugly \
--to=oswald.buddenhagen@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.