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:
OpenPGP_signature.asc
Description: OpenPGP digital signature
