Junio C Hamano <gitster@xxxxxxxxx> writes: > Joey Hess <id@xxxxxxxxxx> writes: > >> Please also revert it, or at least the portions for >> and symlinkPointsToGitDir and symlinkTargetLength. The >> checks for symlinkTargetBlob and symlinkTargetMissing seem worth >> keeping. > > Looking at the change in question, in a33fea08 (fsck: warn about > symlink pointing inside a gitdir, 2024-04-10), you said: > ... > So, I am ambivalent. I have prepared a revert queued on maint-2.39 > and cascaded it up to the maintenance track, which I tentatively > queued on top of 'seen', to see how much damage such a reversion > involves (and it did not look too bad), but > > (1) I am not sure if this is such a huge deal that requires a > revert; > > (2) I am not sure which one is more practical between ripping > everything out and demoting these new fsck error types with > FSCK_WARN to FSCK_IGNORE. If the structure of the code to > perform these checks is more or less good and the actual check > the code implements is bad, the latter might give us a better > foundation to build on than rebuilding everything from scratch. > On the other hand, if we are redoing things in the open, it may > be better to forget about the code in 2.45.1/2.39.4 and to build > from scratch for those reviewers and developers who will offer > help. > > (3) As I look at the change by a33fea08 again, it actually adds a > few new fsck error types with FSCK_ERROR. Perhaps that is a > good enough reason to do a straight revert for now? > > Thanks. It is past my bedtime so I won't be pushing out the 'seen' > with the revert I prepared as a practice, at least tonight. So at least for now, I've queued a full revert of the change in question in the "revert over-eager layering-on-top changes" pile, but as we haven't really seen anybody give good input to help me decide what to do with this step, the pile is still kept outside of the 'next' branch. At least it is visible on 'seen' as of tonight. Thanks.
