On Tue, Feb 16 2021, Jeff King wrote: > While there are some minor security implications to having these files > be symlinks, this is out-weighed by the inconvenience of blocking > historical commits in some projects that might include them. Digging up the relevant thread that's the projects noted at https://lore.kernel.org/git/20201027033518.GH2645313@xxxxxxxxxx/ ? I cloned the openmrn.git repository noted there, and checkout dies with: error: invalid path 'applications/clinic_app/targets/linux.x86/.gitignore' fatal: Could not reset index file to revision 'HEAD'. I'm running a recent-ish snapshot of next at d98b1dd5eaa7, so with your verify_path() change in current "seen". So this series changes nothing about the checkout, just the fsck check? I see there's your https://lore.kernel.org/git/20201027075853.GH3005508@xxxxxxxxxxxxxxxxxxxxxxx/#t to improve the !!symlink() codepath in apply.c Still, it seems like a rather jarring gap in implementation to just warn about this in fsck for the benefit of e.g. server operations, but then hard die on the current client. There seems to be no way around that hard die, and both repos in that report are ones that are just symlinking .gitignore to a ../somedir/.gitignore deep in their own tree. So aren't we both making the fsck check too loose and the client too strict? Would anyone care if this was an error on fsck if we did the "is outside repo?" check?
