From: "brian m. carlson" <sandals@crustytoothpaste•net>
To: Andrej Zhilenkov <azhilenkov@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: Update symlinks after changing core.symlinks
Date: Fri, 4 Apr 2025 07:31:27 +0000 [thread overview]
Message-ID: <Z--Kz4jsRzm4VSZd@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <CAArAzAr+YPwVXJo8mjkyQG8uWv=wt89tYyp6TL-rNzvwVYm9YA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2025-04-04 7:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 7:18 Update symlinks after changing core.symlinks Andrej Zhilenkov
2025-04-02 22:41 ` brian m. carlson
2025-04-03 22:25 ` brian m. carlson
2025-04-04 5:51 ` Andrej Zhilenkov
2025-04-04 7:31 ` brian m. carlson [this message]
2025-04-10 19:29 ` Andrej Zhilenkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z--Kz4jsRzm4VSZd@tapette.crustytoothpaste.net \
--to=sandals@crustytoothpaste$(echo .)net \
--cc=azhilenkov@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox