From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: phillip.wood@dunelm.org.uk, Jeff King <peff@peff.net>,
Philip Peterson via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>,
Emily Shaffer <nasamuffin@google.com>,
Philip Peterson <philip.c.peterson@gmail.com>
Subject: Re: [PATCH 0/5] promise: introduce promises to track success or error
Date: Tue, 20 Feb 2024 08:20:42 -0800 [thread overview]
Message-ID: <xmqqa5nvumxx.fsf@gitster.g> (raw)
In-Reply-To: <ZdSYxF3Hd6Zqt3Wd@tanuki> (Patrick Steinhardt's message of "Tue, 20 Feb 2024 13:19:16 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> While we're already at it throwing ideas around, I also have to wonder
> whether this would be a long-term solution towards computer-friendly
> errors. One of the problems we quite frequently hit in Gitaly is that we
> are forced to parse error messages in order to figure out why exactly
> something has failed. Needless to say, this is quite fragile and also
> feels very wrong.
>
> Now if we had a more structured way to pass errors around this might
> also enable us to convey more meaning to the caller of Git commands. In
> a hypothetical world where all errors were using an explicit error type,
> then this error type could eventually become richer and contain more
> information that is relevant to the calling script. And if such rich
> error information was available, then it would not be that far fetched
> to ask Git to emit errors in a computer-parsable format like for example
> JSON.
I do not know about the "JSON-parseable" part, but a structured
error message, or even just a set of error codes that can be
recorded in an index, might already be a great improvement.
next prev parent reply other threads:[~2024-02-20 16:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-18 7:33 [PATCH 0/5] promise: introduce promises to track success or error Philip Peterson via GitGitGadget
2024-02-18 7:33 ` [PATCH 1/5] promise: add promise pattern to track success/error from operations Philip Peterson via GitGitGadget
2024-02-18 7:33 ` [PATCH 2/5] apply: use new promise structures in git-apply logic as a proving ground Philip Peterson via GitGitGadget
2024-02-18 7:33 ` [PATCH 3/5] apply: update t4012 test suite Philip Peterson via GitGitGadget
2024-02-18 7:33 ` [PATCH 4/5] apply: pass through quiet flag to fix t4150 Philip Peterson via GitGitGadget
2024-02-18 7:33 ` [PATCH 5/5] am: update test t4254 by adding the new error text Philip Peterson via GitGitGadget
2024-02-19 14:25 ` [PATCH 0/5] promise: introduce promises to track success or error Phillip Wood
2024-02-20 2:57 ` Jeff King
2024-02-20 10:53 ` Phillip Wood
2024-02-20 12:19 ` Patrick Steinhardt
2024-02-20 16:20 ` Junio C Hamano [this message]
2024-02-21 18:03 ` Jeff King
2024-03-12 4:18 ` Philip
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=xmqqa5nvumxx.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=johannes.schindelin@gmx.de \
--cc=nasamuffin@google.com \
--cc=peff@peff.net \
--cc=philip.c.peterson@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
/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.