On Sat, Oct 14, 2023 at 09:10:22AM -0700, Junio C Hamano wrote:
> > @@ -461,8 +449,10 @@ struct commit_graph *parse_commit_graph(struct repo_settings *s,
> > }
> >
> > if (s->commit_graph_read_changed_paths) {
> > + if (pair_chunk_expect(cf, GRAPH_CHUNKID_BLOOMINDEXES,
> > + &graph->chunk_bloom_indexes,
> > + st_mult(graph->num_commits, 4)) == -1)
> > + warning(_("commit-graph changed-path index chunk is too small (%d)"), graph->num_commits * 4);
> > read_chunk(cf, GRAPH_CHUNKID_BLOOMDATA,
> > graph_read_bloom_data, graph);
> > }
>
> Overall the series looked sane, but the need for each caller to
> supply error messages, when the helper perfectly well knows how many
> bytes the caller expected and how many bytes there are avaiable, was
> a bit disturbing, as the level of detail given per each caller will
> inevitably become uneven. Even now, some give an error() while
> others give a warning(), even though I suspect all of them should be
> data errors.
>
> I wonder if it makes sense to stuff the message template in the
> pair_chunk_data structure and do
>
> static int pair_chunk_expect_fn(const unsigned char *chunk_start,
> size_t chunk_size,
> void *data)
> {
> struct pair_chunk_data *pcd = data;
> if (pcd->expected_size != chunk_size)
> return error(_(pcd->message), pcd->expected_size, chunk_size);
> *pcd->p = chunk_start;
> return 0;
> }
One issue with the series as-is is that the "chunk is too small"
messages can be misleading when the chunk is in fact missing. We do say
"missing or corrupt" in the die message (at least for midx; I did not
update the similar ones for commit-graph), but the explicit "too small"
for a missing chunk seems to me to cross the line.
The caller can distinguish the cases by the actual value returned from
pair_chunk_expect(), but doing so makes the code a lot longer and harder
to read.
Your suggestion above takes care of it naturally (in the same way that
the existing code does, which basically is emitting the same message in
each read_chunk callback).
-Peff
