Subject: Re: Update symlinks after changing core.symlinks

From: "brian m. carlson" <[email-masked]>
Date: Fri, 4 Apr 2025 07:31:27 +0000

On 2025-04-04 at 05:51:21, Andrej Zhilenkov wrote:
> Just recently started working with symlinks in git and I've found that
> in Git for Windows they are disabled by default
> (https://gitforwindows.org/symbolic-links.html).

Yes, that's true.  On Windows, symlinks require elevated privileges to
create by default unless you're in Developer Mode (which I highly
recommend for Git users and developers).  That's the main reason they're
disabled by default: because they simply can't be created in many cases.

> It's possible to just change the setting in system config or override
> it in global config, but it's probably safe to assume that the average
> Windows user will have them disabled.

I think it depends.  If you're working in software development, you
really should have them enabled and many users will, but I agree some
users may not (say, because they're in a corporate environment and
they're not permitted).

> And if your repo needs them, it's probably more reasonable to ask the
> user to enable symlinks in a local config, not global.

Ah, there I disagree.  I think if you have privileges to create
symlinks, you probably want them to always be enabled, and if not, you
don't really have a choice and they'll be disabled.  My experience with
using repositories with symbolic links is that typically they don't
function at all (or, if the maintainer has taken great care, only with
greatly reduced functionality) if the symlinks are missing.  I think
Git's repository is by far the exception here.

> Maybe there are similar cases but on Unix when users would want
> `core.symlinks` disabled globally and be enabled on a per-repo basis
> but I can't imagine why.

I have certainly seen cases on Unix systems where symlinks didn't work.
For instance, they don't work on FAT-based file systems, and I have also
seen a Linux distro that tried to restrict symlink creation to work only
when the creating user owned the destination file, which breaks Git's
symlink functionality (I quickly demonstrated this "security" feature
could be trivially bypassed).

However, I don't think there's generally a situation in which you'd
_want_ it to be disabled globally.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA