Subject: Re: [PATCH 1/2] fsck: make symlinked .gitignore and .gitattributes a warning

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Tue, 16 Feb 2021 01:38:30 +0100

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/[email-masked]/ ?

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/[email-masked]/#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?