Re: [GSoC][PATCH v13 02/10] fsck: add a unified interface for reporting fsck messages
From: Patrick Steinhardt <hidden>
Date: 2024-07-30 08:31:26
On Mon, Jul 29, 2024 at 09:26:30PM +0800, shejialuo wrote:
The static function "report" provided by "fsck.c" aims at checking fsck error type and calling the callback "error_func" to report the message. However, "report" function is only related to object database which cannot be reused for refs.
Nit: it would be nice to mention _why_ it cannot be reused for refs.
quoted hunk ↗ jump to hunk
diff --git a/fsck.c b/fsck.c index 3f32441492..1185e9a8ad 100644 --- a/fsck.c +++ b/fsck.c@@ -226,12 +226,18 @@ static int object_on_skiplist(struct fsck_options *opts, return opts && oid && oidset_contains(&opts->skip_oids, oid); } -__attribute__((format (printf, 5, 6))) -static int report(struct fsck_options *options, - const struct object_id *oid, enum object_type object_type, - enum fsck_msg_id msg_id, const char *fmt, ...) +/* + * Provide a unified interface for either fscking refs or objects. + * It will get the current msg error type and call the error_func callback + * which is registered in the "fsck_options" struct. + */ +static int fsck_vreport(struct fsck_options *options, + const struct object_id *oid, + enum object_type object_type, + const struct fsck_refs_info *refs_info, + enum fsck_msg_id msg_id, const char *fmt, va_list ap) { - va_list ap; + va_list ap_copy; struct strbuf sb = STRBUF_INIT; enum fsck_msg_type msg_type = fsck_msg_type(msg_id, options); int result;
It is a bit weird that this new generic function receives non-generic inputs which are specific to the respective subsystems (objects or refs) that we are checking. A better design would likely be to make `error_func()` receive a void pointer such that `error_func()` and then have the respective subsystems provide a function that knows to format the message while receiving either a `struct fsck_object_report *` or a `struct fsck_ref_report *`. I don't think this is particularly worriesome though as it is still manageable right now. So I'm fine if we want to leave this as-is, and then we can iterate on this in a future patch series as required.
quoted hunk ↗ jump to hunk
@@ -250,9 +256,9 @@ static int report(struct fsck_options *options, prepare_msg_ids(); strbuf_addf(&sb, "%s: ", msg_id_info[msg_id].camelcased); - va_start(ap, fmt); - strbuf_vaddf(&sb, fmt, ap); - result = options->error_func(options, oid, object_type, + va_copy(ap_copy, ap); + strbuf_vaddf(&sb, fmt, ap_copy); + result = options->error_func(options, oid, object_type, refs_info, msg_type, msg_id, sb.buf); strbuf_release(&sb); va_end(ap);@@ -260,6 +266,35 @@ static int report(struct fsck_options *options, return result; } +__attribute__((format (printf, 5, 6))) +static int report(struct fsck_options *options, + const struct object_id *oid, enum object_type object_type, + enum fsck_msg_id msg_id, const char *fmt, ...) +{ + va_list ap; + int result; + + va_start(ap, fmt); + result = fsck_vreport(options, oid, object_type, NULL, msg_id, fmt, ap); + va_end(ap); + + return result; +}
As far as I can see, `report()` is now specific to reporting errors with objects while `fsck_vreport()` is the generic part. Do we want to rename the function to `fsck_report_object()` to clarify, or would that cause too much churn? Hm. Seeing that we have 62 callsites of that function it may be too much churn indeed.
quoted hunk ↗ jump to hunk
+int fsck_refs_report(struct fsck_options *options, + const struct object_id *oid, + const struct fsck_refs_info *refs_info, + enum fsck_msg_id msg_id, const char *fmt, ...)
Would `fsck_report_ref()` be a better name? What is the intent of the `oid` field? Would it be set to the object ID that a reference points to? What if the reference is a non-resolving symbolic reference? I wonder whether we can just remove it. Patrick
Attachments
- signature.asc [application/pgp-signature] 833 bytes