shejialuo <shejialuo@xxxxxxxxx> writes:
> -static int fsck_error_func(struct fsck_options *o UNUSED,
> +static int fsck_error_func(struct fsck_objects_options *o UNUSED,
> const struct object_id *oid,
> enum object_type object_type,
> enum fsck_msg_type msg_type,
It is curious that the addition/renaming of fsck_objects_options is
presumably to allow fsck_${xyzzy}_options to be added for different
$xyzzy (the first one being "refs"), and this function is only about
fsck_objects_options. What name would the corresponding error
function, called by checkers that take fsck_${xyzzy}_options, be
given? fsck_${xyzzy}_error_func()? Shouldn't this be then become
fsck_objects_error_func() or something?
Having said that.
Do we really need such a parallel system between "objects" and other
kinds of things being checked that you are introducing with this
step? What benefit are we getting from this additional complexity?
I would have expected that adding ref-related new members that
object consistency checkers has no interest in to the fsck_options
structure would be sufficient for the purpose of this series. Or if
we really wanted to prepare for more complex future, use of the
"union of variants, switched with a tag" pattern to arrange the data
this way:
struct fsck_options {
enum fsck_type {
FSCK_OBJECTS,
FSCK_REFS,
...
} t;
union {
struct fsck_objects_options objects;
struct fsck_refs_options refs;
} u;
};
would still allow functions like fsck_error_func(), and
fsck_set_msg_types(), etc. to work on the common "fsck_options".
I dunno.
