Subject: Re: [PATCH v2 0/4] add ref content check for files backend

From: Patrick Steinhardt <[email-masked]>
Date: Thu, 29 Aug 2024 09:00:58 +0200

On Wed, Aug 28, 2024 at 09:59:58PM -0700, Junio C Hamano wrote:
> Jeff King <[email-masked]> writes:
> 
> > As an aside, I wonder if we should consider deprecating and eventually
> > dropping support for core.prefersymlinkrefs. I can't think of a reason
> > anybody would want to use it, and of course it makes no sense as we move
> > on to alternate backends like reftables.
> 
> Yup.  Perhaps add an entry or two to BreakingChanges document?
> 
>  Documentation/BreakingChanges.txt | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git c/Documentation/BreakingChanges.txt w/Documentation/BreakingChanges.txt
> index 0532bfcf7f..2a85740f3c 100644
> --- c/Documentation/BreakingChanges.txt
> +++ w/Documentation/BreakingChanges.txt
> @@ -115,6 +115,12 @@ info/grafts as outdated, 2014-03-05) and will be removed.
>  +
>  Cf. <[email-masked]>.
>  
> +* Support for core.prefersymlinkrefs will be dropped.  Support for
> +  existing repositories that use symbolic links to represent a
> +  symbolic ref may or may not be dropped.
> ++
> +Cf. <[email-masked]>
> +
>  == Superseded features that will not be deprecated

Yes, I'm very much in favor of that. As Peff said, I don't see a single
reason why it would make sense to use symlinks nowadays. We have also
supported the "new" syntax for ages now, and I'd be surprised if there
were repos out there using it on purpose.

We should probably do the above together with a new check that starts to
warn about symbolic links in "refs/" such that users become aware of
this deprecation. We'd have to grow the infrastructure to also scan root
refs though, which to the best of my knowledge we don't currently scan.

Patrick