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

From: Jeff King <peff@peff.net>
Date: Feb 16, 2021, 12:54 UTC
Message-ID: <YCvAmkO8ZQnlp4m9@coredump.intra.peff.net>
In-Reply-To: <xmqqtuqcsrkt.fsf@gitster.c.googlers.com>

On Mon, Feb 15, 2021 at 05:56:50PM -0800, Junio C Hamano wrote:

Show 9 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > That said, they'd probably want to checkout those old commits, too. So
> > we probably do need a config override, even if it's a broad one ("trust
> > me, this repo is OK, just allow symlinks for these special files").
> 
> Is this about the check that is overly strict for some existing
> projects that kept the jk/symlinked-dotgitx-files topic in the
> 'seen' so far?

Yes.

> On the fsck end, we know we can demote the error level per
> repository, but I wonder if we should make checkout/clone honor the
> same setting?

What would the default be? If it's permissive, then it feels like we are not really solving much, as anybody who wanted to be careful can already inspect the tree contents. This is about avoiding surprises in the default config.

If it's to forbid by default, then yes, I think the "trust me this repo is OK" I gave above would be a viable path forward.

Show 5 quoted lines

> I think GITMODULES_SYMLINK has been there for quite some time at
> "error" level and we do want to discourage it to be a symbolic link,
> so I am not quite sure what the demoting of these two achieves.  Why
> aren't we having a similar issue on .gitmodules that is a symbolic
> link?

I think it's just less common to have symlinked .gitmodules. To be clear, I think symlinked .gitignore is also pretty uncommon. Back when we discussed this originally in 2018 I scanned most of GitHub and came up with only a handful of repositories that did so.

-Peff