All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.