commit-graph: detect read errors when verifying graph chain
commit47d06bb010867cd122f732be93e55a797371570c
authorJeff King <peff@peff.net>
Thu, 28 Sep 2023 04:38:59 +0000 (28 00:38 -0400)
committerJunio C Hamano <gitster@pobox.com>
Thu, 28 Sep 2023 14:00:43 +0000 (28 07:00 -0700)
tree23b0d545721e3d419ec9354b976ce53d0f59c7c4
parent2d45710c5d1dc20db0d6c856e9e711dd6a19e18f
commit-graph: detect read errors when verifying graph chain

Because it's OK to not have a graph file at all, the graph_verify()
function needs to tell the difference between a missing file and a real
error.  So when loading a traditional graph file, we call
open_commit_graph() separately from load_commit_graph_chain_fd_st(), and
don't complain if the first one fails with ENOENT.

When the function learned about chain files in 3da4b609bb (commit-graph:
verify chains with --shallow mode, 2019-06-18), we couldn't be as
careful, since the only way to load a chain was with
read_commit_graph_one(), which did both the open/load as a single unit.
So we'll miss errors in chain files we load, thinking instead that there
was just no chain file at all.

Note that we do still report some of these problems to stderr, as the
loading function calls error() and warning(). But we'd exit with a
successful exit code, which is wrong.

We can fix that by using the recently split open/load functions for
chains. That lets us treat the chain file just like a single file with
respect to error handling here.

An existing test (from 3da4b609bb) shows off the problem; we were
expecting "commit-graph verify" to report success, but that makes no
sense. We did not even verify the contents of the graph data, because we
couldn't load it! I don't think this was an intentional exception, but
rather just the test covering what happened to occur.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/commit-graph.c
t/t5324-split-commit-graph.sh