ab/refs-errno-cleanup & "errno" removal in the refs backend

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 6, 2021, 10:26 UTC
Message-ID: <87ee8yiguc.fsf@evledraar.gmail.com>
In-Reply-To: <xmqqo884tkxd.fsf@gitster.g>

On Mon, Oct 04 2021, Junio C Hamano wrote:

Show 9 quoted lines

> * ab/refs-errno-cleanup (2021-08-25) 4 commits
>  - refs: make errno output explicit for refs_resolve_ref_unsafe
>  - refs: explicitly return failure_errno from parse_loose_ref_contents
>  - branch tests: test for errno propagating on failing read
>  - refs: add failure_errno to refs_read_raw_ref() signature
>
>  The "remainder" of hn/refs-errno-cleanup topic.
>
>  What's the status of this one?  Meh?

(For bystanders, this is ab/*, but it's mostly/entirely Han-Wen's work, although I did modify it a bit. It's patch 5-8/8 of [1])

I tried advocating for it the last time around[2], maybe this helps more: The "errno" variable is still an explicit/implicit part of the refs API, so any backend that doesn't deal with files (i.e. reftable) is likely to have subtle bugs or missing behavior if we don't eliminate it completely at the API boundaries.

This is a start of that, I've got a 8-patch series (largely code deletion/making things "static") that gets us to that point queued up after this.

We'll still be returning errno, just via a variable, and reftable will be faking it up. But once we've gotten to that point it's easy to continue and e.g. making these backends return some structured sensible return values via enums or whatever. I don't have anything planned/written to do that, but that seems logical once we've got "reftable" in addition to the files backend, and perhaps in the future a generic DB backends or whatever.

1. https://lore.kernel.org/git/patch-v10-5.8-fa9260f25fa-20210823T114712Z-avarab@gmail.com/
2. https://lore.kernel.org/git/87zgrnjw7v.fsf@evledraar.gmail.com/