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

From: Patrick Steinhardt <ps@pks.im>
Date: Feb 20, 2024, 12:19 UTC
Message-ID: <ZdSYxF3Hd6Zqt3Wd@tanuki>
In-Reply-To: <70a81f5a-32d8-4517-83ea-8019be5f97d5@gmail.com>

On Tue, Feb 20, 2024 at 10:53:06AM +0000, Phillip Wood wrote:

Show 25 quoted lines

> 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/20171103191309.sth4zjokgcupvk2e@sigill.intra.peff.net/
> > 
> > that also references this earlier thread:
> > 
> >    https://lore.kernel.org/git/20160927191955.mympqgylrxhkp24n@sigill.intra.peff.net/
> 
> 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