]> git.ipfire.org Git - thirdparty/git.git/commit
refs: remove EINVAL errno output from specification of read_raw_ref_fn
authorHan-Wen Nienhuys <hanwen@google.com>
Mon, 23 Aug 2021 11:52:38 +0000 (13:52 +0200)
committerJunio C Hamano <gitster@pobox.com>
Wed, 25 Aug 2021 20:30:26 +0000 (13:30 -0700)
commit20d422cfd7f41df671bf98972ff89d68dfa0ed7b
tree34472e06a82ae8d675eccc9ffbf100262a258f44
parent3fa2e91d173b260c19f19af8edd3907e65bf85f7
refs: remove EINVAL errno output from specification of read_raw_ref_fn

This commit does not change code; it documents the fact that an alternate ref
backend does not need to return EINVAL from read_raw_ref_fn to function
properly.

This is correct, because refs_read_raw_ref is only called from;

* resolve_ref_unsafe(), which does not care for the EINVAL errno result.

* refs_verify_refname_available(), which does not inspect errno.

* files-backend.c, where errno is overwritten on failure.

* packed-backend.c (is_packed_transaction_needed), which calls it for the
  packed ref backend, which never emits EINVAL.

A grep for EINVAL */*c reveals that no code checks errno against EINVAL after
reading references. In addition, the refs.h file does not mention errno at all.

A grep over resolve_ref_unsafe() turned up the following callers that inspect
errno:

* sequencer.c::print_commit_summary, which uses it for die_errno

* lock_ref_oid_basic(), which only treats EISDIR and ENOTDIR specially.

The files ref backend does use EINVAL. The files backend does not call into
the generic API (refs_read_raw), but into the files-specific function
(files_read_raw_ref), which we are not changing in this commit.

As the errno sideband is unintuitive and error-prone, remove EINVAL
value, as a step towards getting rid of the errno sideband altogether.

Spotted by Ævar Arnfjörð Bjarmason <avarab@gmail.com>.

Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
refs/refs-internal.h