[PATCH 0/4] deprecating core.preferSymlinkRefs

[Junio C Hamano <gitster@pobox.com>]

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.

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.

Junio C Hamano (4):
  refs: deprecate core.preferSymlinkRefs
  refs: mostly remove core.preferSymlinkRefs
  refs: remove NO_SYMLINK_HEAD
  refs: remove the last remnants of core.preferSymlinkRefs

 Documentation/BreakingChanges.txt   | 11 ++++++++
 Documentation/config/core.txt       |  6 -----
 Makefile                            |  6 -----
 config.c                            |  5 ----
 config.mak.uname                    |  3 ---
 configure.ac                        |  3 ---
 contrib/buildsystems/CMakeLists.txt |  2 +-
 environment.c                       |  1 -
 environment.h                       |  1 -
 refs/files-backend.c                | 26 -------------------
 t/t0600-reffiles-backend.sh         | 39 ++++++++++++++++-------------
 11 files changed, 34 insertions(+), 69 deletions(-)

-- 
2.46.1-742-g4240f61078