On Mon, Jul 29, 2024 at 09:22:52PM +0800, shejialuo wrote: > Hi All: > > This version mainly focuses on the problem about how should we provide > extensibility for reporting the problem of refs. In patch v10, Junio > asked a question here: > > > The error reporting function for refs consistency check was still > > about reporting a problem for a single ref. I am wondering how > > consistency violations that are not about a single ref should be > > handled. For example, if refs/packed-backend.c:packed_fsck() finds > > that the file is not sorted properly or has some unparseable garbage > > in it, it is not something you can report as "refs/heads/main is > > broken", but those who are interested in seeing the "reference > > database consistency" verified, it is very much what they want the > > tool to notice. How would detection of such a breakage that is not > > attributed to a single ref fit in this "ref consistency check > > infrastructure" that was introduced by [05/10]? > > Actually, I think that the original parameter "checked_ref_name" is a > bad name which makes the reader think that "we only handle refs". And > this is my fault for this design. However, I misunderstood the Junio's > word and made things complicated. > > The patch v11 and v12 wants to solve a problem that we should provide > extensibility for reporting refs problem. However, these two versions > still made things complicated. After an offline meeting with Patrick and > Karthik, we design the following simple flat data structure: > > struct fsck_refs_info { > const char *path; > }; > > It is simple and provides extensibility. I've got a bunch of comments, mostly because I've been out for quite a while and thus didn't follow the progression of this series. But don't let yourself be discouraged by the volume, I quite like the shape of this patch series and think that it is very close to what we actually want to have. I'd say that this series is likely to become ready soonish. Thanks! Patrick
Attachment:
signature.asc
Description: PGP signature