user/sven/git.git/compat, branch origin/maint

Merge branch 'js/symlink-windows'

2026-01-23T21:34:37Z

Upstream symbolic link support on Windows from Git-for-Windows. * js/symlink-windows: mingw: special-case index entries for symlinks with buggy size mingw: emulate `stat()` a little more faithfully mingw: try to create symlinks without elevated permissions mingw: add support for symlinks to directories mingw: implement basic `symlink()` functionality (file symlinks only) mingw: implement `readlink()` mingw: allow `mingw_chdir()` to change to symlink-resolved directories mingw: support renaming symlinks mingw: handle symlinks to directories in `mingw_unlink()` mingw: add symlink-specific error codes mingw: change default of `core.symlinks` to false mingw: factor out the retry logic mingw: compute the correct size for symlinks in `mingw_lstat()` mingw: teach dirent about symlinks mingw: let `mingw_lstat()` error early upon problems with reparse points mingw: drop the separate `do_lstat()` function mingw: implement `stat()` with symlink support mingw: don't call `GetFileAttributes()` twice in `mingw_lstat()`

Merge branch 'js/prep-symlink-windows'

2026-01-21T16:29:00Z

Further preparation to upstream symbolic link support on Windows. * js/prep-symlink-windows: trim_last_path_component(): avoid hard-coding the directory separator strbuf_readlink(): support link targets that exceed 2*PATH_MAX strbuf_readlink(): avoid calling `readlink()` twice in corner-cases init: do parse _all_ core.* settings early mingw: do resolve symlinks in `getcwd()`

mingw: emulate `stat()` a little more faithfully

2026-01-10T02:32:55Z

When creating directories via `safe_create_leading_directories()`, we might encounter an already-existing directory which is not readable by the current user. To handle that situation, Git's code calls `stat()` to determine whether we're looking at a directory. In such a case, `CreateFile()` will fail, though, no matter what, and consequently `mingw_stat()` will fail, too. But POSIX semantics seem to still allow `stat()` to go forward. So let's call `mingw_lstat()` to the rescue if we fail to get a file handle due to denied permission in `mingw_stat()`, and fill the stat info that way. We need to be careful to not allow this to go forward in case that we're looking at a symbolic link: to resolve the link, we would still have to create a file handle, and we just found out that we cannot. Therefore, `stat()` still needs to fail with `EACCES` in that case. This fixes https://github.com/git-for-windows/git/issues/2531. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: try to create symlinks without elevated permissions

2026-01-10T02:32:55Z

As of Windows 10 Build 14972 in Developer Mode, a new flag is supported by `CreateSymbolicLink()` to create symbolic links even when running outside of an elevated session (which was previously required). This new flag is called `SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE` and has the numeric value 0x02. Previous Windows 10 versions will not understand that flag and return an `ERROR_INVALID_PARAMETER`, therefore we have to be careful to try passing that flag only when the build number indicates that it is supported. For more information about the new flag, see this blog post: https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/ Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: add support for symlinks to directories

2026-01-10T02:32:55Z

Symlinks on Windows have a flag that indicates whether the target is a file or a directory. Symlinks of wrong type simply don't work. This even affects core Win32 APIs (e.g. `DeleteFile()` refuses to delete directory symlinks). However, `CreateFile()` with FILE_FLAG_BACKUP_SEMANTICS does work. Check the target type by first creating a tentative file symlink, opening it, and checking the type of the resulting handle. If it is a directory, recreate the symlink with the directory flag set. It is possible to create symlinks before the target exists (or in case of symlinks to symlinks: before the target type is known). If this happens, create a tentative file symlink and postpone the directory decision: keep a list of phantom symlinks to be processed whenever a new directory is created in `mingw_mkdir()`. Limitations: This algorithm may fail if a link target changes from file to directory or vice versa, or if the target directory is created in another process. It's the best Git can do, though. Signed-off-by: Karsten Blees Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: implement basic `symlink()` functionality (file symlinks only)

2026-01-10T02:32:55Z

Implement `symlink()`. This implementation always creates _file_ symlinks (remember: Windows discerns between symlinks pointing to directories and those pointing to files). Support for directory symlinks will be added in a subseqeuent commit. This implementation fails with `ENOSYS` if symlinks are disabled or unsupported. Signed-off-by: Karsten Blees Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: implement `readlink()`

2026-01-10T02:32:55Z

Implement `readlink()` by reading NTFS reparse points via the `read_reparse_point()` function that was introduced earlier to determine the length of symlink targets. Works for symlinks and directory junctions. Signed-off-by: Karsten Blees Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: allow `mingw_chdir()` to change to symlink-resolved directories

2026-01-10T02:32:55Z

If symlinks are enabled, resolve all symlinks when changing directories, as required by POSIX. Note: Git's `real_path()` function bases its link resolution algorithm on this property of `chdir()`. Unfortunately, the current directory on Windows is limited to only MAX_PATH (260) characters. Therefore using symlinks and long paths in combination may be problematic. Signed-off-by: Karsten Blees Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: support renaming symlinks

2026-01-10T02:32:55Z

Older MSVCRT's `_wrename()` function cannot rename symlinks over existing files: it returns success without doing anything. Newer MSVCR*.dll versions probably do not share this problem: according to CRT sources, they just call `MoveFileEx()` with the `MOVEFILE_COPY_ALLOWED` flag. Avoid the `_wrename()` call, and go with directly calling `MoveFileEx()`, with proper error handling of course. Signed-off-by: Karsten Blees Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

mingw: handle symlinks to directories in `mingw_unlink()`

2026-01-10T02:32:55Z

The `_wunlink()` and `DeleteFileW()` functions refuse to delete symlinks to directories on Windows; The error code would be `ERROR_ACCESS_DENIED` in that case. Take that error code as an indicator that we need to try `_wrmdir()` as well. In the best case, it will remove a symlink. In the worst case, it will fail with the same error code again. Signed-off-by: Karsten Blees Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano