On Wed, Aug 28, 2024 at 09:59:58PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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. <20140304174806.GA11561@xxxxxxxxxxxxxxxxxxxxx>. > > +* 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. <20240829040215.GA4054823@xxxxxxxxxxxxxxxxxxxxxxx> > + > == 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
