Re: [RFC/PATCH 4/3] create_symref: drop support for writing symbolic links

On Tue, Dec 29, 2015 at 10:32:04AM -0800, Junio C Hamano wrote:

Here's the first step of that multi-step process. The commit message will look familiar, as the rationale for deprecating is the same as for dropping.

This is on top of what I posted earlier (it obviously could be independent, but I assume we're planning to merge the other bits, and I don't mind holding this topic hostage for a little while to save some annoying merging).

-- >8 --
Subject: [PATCH] create_symref: deprecate support for writing symbolic links

Long ago, in 2fabd21 (Disable USE_SYMLINK_HEAD by default, 2005-11-15), we switched git's default behavior to writing text symrefs instead of symbolic links. Any scripts accustomed to looking directly at .git/HEAD were updated to use `rev-parse` instead. The Linux kernel's setlocalversion script was one, and it was fixed in 117a93d (kbuild: Use git in scripts/setlocalversion, 2006-01-04).

However, the problem still happened when bisecting the kernel; pre-117a93d would not build properly with a newer git, because they wanted to look directly at HEAD. To solve this, we added 9f0bb90 (core.prefersymlinkrefs: use symlinks for .git/HEAD, 2006-05-02), which lets the user turn on the old behavior, theoretically letting you bisect older kernel history.

But there are a few complications with this solution:

  - packed-refs means you are limited in what you can do
    with .git/HEAD. If it is a symlink, you may `readlink`
    it to see where it points, but you cannot necessarily
    `cat .git/HEAD` to get the sha1, as the pointed-to ref
    may be packed.

    In particular, this means that the pre-117a93d kbuild
    script would sometimes work and sometimes not.

  - These days, we bisect on a detached HEAD. So during
    bisection, .git/HEAD _is_ a regular file with the
    sha1, and it works to `cat` it, whether or not you set
    core.preferSymlinkRefs.

Such scripts will all be broken again if we move to alternate ref backends. They should have learned to use `rev-parse` long ago, and it is only bisecting ancient history that is a problem.

Now that almost ten years have passed, it seems less likely that developers will bisect so far back in history. And moreover, this is but one of many possible problems developers run into when trying to build versions. The standard solution is to apply a "fixup" patch or other workaround while test-building the project, and that would work here, too.

This patch therefore deprecates core.preferSymlinkRefs completely. There are a few reasons to want to do so:

  1. It drops some code that is probably exercised very
     rarely.

  2. The symlink code is not up to the same standards as the
     rest of the ref code. In particular, it is racy with
     respect to simultaneous readers and writers.

  3. If we want to eventually drop the symlink-reading code,
     this is a good first step to deprecating it.

We print a deprecation warning anytime a symlink is created using this code. That prevents us from spamming the user with multiple warnings from read-only operations, but catches major operations like init, clone, and checkout.

Signed-off-by: Jeff King <peff@peff.net>
---
There's no advice.* safety valve here. The solution is "fix your
script", and the last-ditch effort is "come to the mailing list and tell
us why it would be a bad thing to remove the feature".

 refs/files-backend.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)