Re: [PATCH 0/3] Strengthen fsck checks for submodule URLs

[Neil Mayhew <neil@mayhew.name>]

[-- Attachment #1.1: Type: text/plain, Size: 1509 bytes --]

On 10 Jan 24 03:23, Jeff King wrote:
 > By making it an fsck
 > check, though, any mistakes that are embedded in history (even if
 > they are now corrected) will make it a pain to use the repository
 > with sites that enable transfer.fsckObjects.
 >
 > My gut feeling is that this is probably OK in practice. If it does
 > cause pain, we might consider loosening the fsck.gitmodulesUrl
 > severity (under the notion from above that it is no longer a
 > critical security check). But if it doesn't cause real-world pain,
 > being pickier is probably better (it may save us from a
 > vulnerability down the road).

This pain is happening in 
https://github.com/IntersectMBO/cardano-ledger.git, a large open-source 
repo. There was a bad edit to .gitmodules which was immediately 
corrected by another commit. However, the bad commit is still in the 
history. It happened 6 years ago, so there's no possibility of us 
changing the history. We just spent time investigating a bug report from 
someone who was unable to clone the repo, and eventually we discovered 
that they had transfer.fsckObjects enabled. Even without this option, 
however, we still want people to be able to run fsck successfully on the 
repo.

It's awkward that our repo now won't pass an fsck check and we have no 
way to correct that. I'd really like not to have to put a note in the 
README warning about this.

Is there any possibility of "loosening the fsck.gitmodulesUrl severity", 
as Jeff suggested?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]