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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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

> * 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/