Subject: Re: [PATCH 0/5] promise: introduce promises to track success or error

From: Patrick Steinhardt <[email-masked]>
Date: Tue, 20 Feb 2024 13:19:16 +0100

On Tue, Feb 20, 2024 at 10:53:06AM +0000, Phillip Wood wrote:
> Hi Peff
> 
> On 20/02/2024 02:57, Jeff King wrote:
> > On Mon, Feb 19, 2024 at 02:25:29PM +0000, Phillip Wood wrote:
> > 
> > > I'm sure this has been discussed in the past but I didn't manage to turn
> > > anything up with a quick search of the archive on lore.kernel.org.
> > 
> > There's some discussion in this sub-thread:
> > 
> >    https://lore.kernel.org/git/[email-masked]/
> > 
> > that also references this earlier thread:
> > 
> >    https://lore.kernel.org/git/[email-masked]/
> 
> Thanks for digging up those links
> 
> > I still think this is a reasonable way to go. At one point I had a
> > proof-of-concept conversion of some of the ref code, but I don't think I
> > have it any more.
> 
> Ah, that's interesting - the ref transaction functions already take a struct
> strbuf to populate with an error message so maybe that would be a simple
> place to start with a conversion to an error struct.

I would certainly welcome such a change. It might make sense to wait a
bit until the reftable dust has settled, but once that code has landed
I'd be quite happy to see improvements to our error handling.

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.

Patrick