Re: [PATCH 0/4] deprecating core.preferSymlinkRefs

[Patrick Steinhardt <ps@pks.im>]

On Wed, Sep 18, 2024 at 04:28:21PM -0700, Junio C Hamano wrote:
> Removal of support for core.preferSymlinkRefs at Git 3.0 boundary,
> so that we only write textual symrefs for things like HEAD and
> refs/remotes/origin/HEAD, and still understand symbolic links used
> as symrefs in existing repositories, is a serious proposal this
> patch series makes.

I probably don't have have to say that I fully support dropping support
for the writing side of this :) I was also recently reminded that we
still have ".git/branches", which I'd very much like to drop support for
with Git 3.0, too. I'll send a separate patch series for that soonish.

> But at the same time, this is an RFC.  I wrote it to serve as a
> candidate for BCP, a guide to those who want to add an entry to the
> breaking changes document.  I think anything that is described in
> the breaking changes document has to become a patch series that
> spans multi-year effort, and that must be done with care.
> 
>  - The proposal phase.  A breaking change is outlined, transition
>    plan is given, and the first step of the transition (often,
>    starting to give a warning and offering an alternative to the
>    feature planned to be removed are involved) is presented.  The
>    aim is that after N years, the user base will be aware of the
>    upcoming removal and would already be prepared to be able to work
>    with Git 3.0 that lacks the removed feature.
> 
>    In this series, [Patch 1/4] does this.
> 
>  - The Git 3.0 phase.  A breaking change is actually implemented.
>    It optionally can offer help to those who procrastinated until
>    the last-minute to break them, but the feature itself is gone.
> 
>    In this series, [PATCH 2/4] and [Patch 3/4] do this.
> 
>  - Clean-up phase.  If the previous phase added an additional
>    transition help, after M years, such a help meant for transition
>    would be removed.
> 
>    In this series, [PATCH 4/4] does this.
> 
> What I want people to think about is how to ensure quality of the
> Git 3.0 phase.  We can iterate and polish the proposal phase with as
> much time as we want to spend, just like any new feature.  But Git
> 3.0 phase is with a solid deadline, and before that time, we cannot
> remove the feature for real.  Would we cook such steps in 'next'
> forever until the actual Git 3.0?  To those users who are running
> 'next' based Git, it would mean that some of the changes the
> breaking changes document listed would come a lot earlier to them.
> On the other hand, unless we somehow have a way to expose willing
> volunteers an early access to these "big changes", there is no way
> for them to be as stable and tested.  We should not plan to scramble
> and be able to perfect these changes between Git v3.0-rc0 and Git
> v3.0 final.
> 
> Or perhaps use the "experimental.*" configuration stored in the
> user's ~/.gitconfig to let users opt into Git 3.0 features (one of
> which may be that textual symrefs are always used regardless of the
> core.preferSymlinkRefs setting)?  That way, we can merge these big
> changes early without worrying about accidentally affecting the
> end-user population.

I guess you've split this out into a separate discussion by now at [1],
right? I've already commented on that series, so I'm not going to repeat
what I've said here :)

Patrick

[1]: <xmqq7cb77810.fsf@gitster.g>