ab/refs-errno-cleanup

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Oct 1, 2021, 14:48 UTC
Message-ID: <87ee94rdq7.fsf@evledraar.gmail.com>
In-Reply-To: <xmqqh7e18soj.fsf@gitster.g>

On Thu, Sep 30 2021, Junio C Hamano wrote:

Show 10 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
>  (this branch uses ab/refs-files-cleanup and hn/refs-errno-cleanup.)
>
>  The "remainder" of hn/refs-errno-cleanup topic.
>
>  What's the status of this one?  Meh?

I'v got two topics that have been waiting on ab/refs-files-cleanup & hn/refs-errno-cleanup graduating:

A. Post-ab/refs-files-cleanup: cleanup builtin/reflog.c for the state of
   the new API, I did a bare minimum of fixes there in
   ab/refs-files-cleanup, but the end-state doesn't make much sense if
   you aren't considering the history of now-gone OID locking "features".

B. Post-ab/refs-errno-cleanup: Reach the end-state of no refs.c APIs
   relying on, or pretending to rely on "errno" being returned
   upwards. This was previously submitted as[1], but the topic was since
   slimmed down into the current ab/refs-errno-cleanup.

The "B" needs this ab/refs-errno-cleanup. I think (and I think Han-Wen would agree) that it leaves the refs API in a much better state for reftable integration.

1. https://lore.kernel.org/git/cover-00.17-00000000000-20210711T162803Z-avarab@gmail.com/