msys/git: How can I disable git to set core.symlinks = false into local setting by default?

[KSR-Yasuda]

In creating (git init) or cloning (git clone),
msys/git sets local core.symlinks = false.

By this, system (/etc/gitconfig) and global (${HOME}/.gitconfig) settings are both ignored,
unless removing core.symlinks from the local (TARGET_REPOSITORY/.git/config) setting.

Can I prevent git from setting this locally?

% echo $MSYS
winsymlinks:nativestrict

% type git
git is hashed (/usr/bin/git)

% git --version
git version 2.42.0

% git config --show-origin core.symlinks
file:/home/xxxxxxxx/.gitconfig    true

% git init test
Initialized empty Git repository in /c/xxxxxxxx/test/.git/

% cat test/.git/config
[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        symlinks = false
        ignorecase = true

[KSR-Yasuda]

Of course Windows group policy to create symlink is enabled (for Admininistrators and Users);
ln -s command works without admin privilage.

[sskras]

@KSR-Yasuda, you write:

msys/git

Is this MSYS2? What's it the output of uname -a ?

[KSR-Yasuda]

@sskras

Is this MSYS2? What's it the output of uname -a ?

% uname -a
MINGW64_NT-10.0-19045 xxxxxxxx 3.4.9.x86_64 2023-09-15 12:15 UTC x86_64 Msys

[sskras]

Confirming in my setup:

$ uname -a
MINGW64_NT-10.0-19044 DESKTOP-O7JE7JE 3.4.9.x86_64 2023-09-15 12:15 UTC x86_64 Msys

On the other hand, Cygwin does not override core.symlinks by default:

$ uname -a
CYGWIN_NT-10.0-19044 DESKTOP-O7JE7JE 3.4.6-1.x86_64 2023-02-14 13:23 UTC x86_64 Cygwin

$ type git
git is hashed (/usr/bin/git)

$ git --version
git version 2.39.0

$ git config --show-origin core.symlinks
file:/home/saukrs/.gitconfig    true

$ git init test
hint: Using 'master' as the name for the initial branch. This default branch name
  ...
Initialized empty Git repository in /home/saukrs/test/.git/

$ cat test/.git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true

$ (cd test; git config --show-origin core.symlinks)
file:/home/saukrs/.gitconfig    true

Although Git is a bit older (git version 2.39.0).

Git on Midipix also behaves fine – no override during repo init.

[sskras]

Might contain some insight:
https://git-scm.com/docs/git-config#Documentation/git-config.txt-coresymlinks:~:text=The%20default%20is%20true%2C,created

core.symlinks
  ...
  The default is true, except git-clone[1] or git-init[1] will probe and set core.symlinks false if appropriate when the repository is created.

[KSR-Yasuda]

@sskras Your git version v2.39.0 behaved the same: it sets local core.symlinks.

So, by some setting, git command is considering symlink is unsupported, isn't it?
But what setting is the reason...?

Git-for-Windows env (installed separately) does work well without setting local core.symlinks.
Only MSYS env is strange.

[rimrul]

@sskras Your git version v2.39.0 behaved the same: it sets local core.symlinks.

So, by some setting, git command is considering symlink is unsupported, isn't it?

https://github.com/git/git/blob/2e8e77cbac8ac17f94eee2087187fa1718e38b14/setup.c#L2016-L2025

But what setting is the reason...?

Probably https://github.com/msys2/msys2-runtime/blob/d52da7859b7a3c8d183adbc7782af679eacb4da3/winsup/cygwin/path.cc#L1929-L1937

Git-for-Windows env (installed separately) does work well without setting local core.symlinks.

The reason is tricks like git-for-windows/git@51540f330c1

Only MSYS env is strange.

[KSR-Yasuda]

@rimrul So, to manage repos that contain symbolic links,
I had better to use git-for-windows/mingw-w64-x86_64-git package instead of msys/git?

Certainly, git-for-windows/mingw-w64-x86_64-git does not set local core.symlinks.

[KSR-Yasuda]

Perhaps because ln -s fails if source file does not exist?

% ls -a
./  ../

% ln -s foo bar
ln: failed to create symbolic link 'bar': No such file or directory

% touch foo
% ls -a
./  ../  foo

% ln -s foo bar
'bar' -> 'foo'

% ls -l
total 0
lrwxrwxrwx 1 xxxxxxxx xxxxxxxx 3 Oct 24 17:23 bar -> foo
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 0 Oct 24 17:23 foo

% ln --version
ln (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

% pacman -F ln.exe
msys/coreutils 8.32-5 [installed]
    usr/bin/ln.exe
git-for-windows/mingw-w64-x86_64-busybox 1.34.0.19688.985b51cf7-1
    mingw64/libexec/busybox/ln.exe

% type -a ln
ln is aliased to `ln -v'
ln is /usr/bin/ln
ln is /bin/ln
ln is /c/Program Files (x86)/Gow/bin/ln

---

In Git-for-Windows env (that does not set local core.symlinks),
ln -s for non-exist source succeeds.

ln version is the same, v8.32, though.

[KSR-Yasuda]

cf. #2052

[sskras]

Good catch. Just tested and commented there.

[KSR-Yasuda]

Setting ${MSYS} env var other than nativestrict helps it.

% for o in lnk native nativestrict sys; do
>     MSYS="winsymlinks:$o" git init "test.$o"
> done

% find test.* -maxdepth 0 -type d -printf "\n%f\n" -exec cat {}/.git/config \;
test.lnk
[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        ignorecase = true

test.native
[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        ignorecase = true

test.nativestrict
[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        symlinks = false
        ignorecase = true

test.sys
[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
        ignorecase = true

• cf. https://www.cygwin.com/cygwin-ug-net/using-cygwinenv.html#:~:text=to%20not%20set.-,winsymlinks,-%3A%7Blnk%2Cnative%2Cnativestrict

As the comment #4116 (comment), MSYS=winsymlinks:nativestrict fails to create symbolic links if source file does not exist.
Git judges it is unsafe while git repos may have such 'source-missing' symlinks.

Other winsymlinks options allowing non-source-existing link creation,
it goes well without setting local core.symlinks.