Hi, On Wed, 14 Mar 2018, Johannes Sixt wrote: > Am 13.03.2018 um 21:39 schrieb Ævar Arnfjörð Bjarmason: > > Add a INSTALL_SYMLINKS option which if enabled, changes the default > > hardlink installation method to one where the relevant binaries in > > libexec/git-core are symlinked back to ../../bin, instead of being > > hardlinked. > > > > This new option also overrides the behavior of the existing > > NO_*_HARDLINKS variables which in some cases would produce symlinks > > within to libexec/, e.g. "git-add" symlinked to "git" which would be > > copy of the "git" found in bin/, now "git-add" in libexec/ is always > > going to be symlinked to the "git" found in the bin/ directory. > > It is important to leave the default at hard-linking the binaries, because on > Windows symbolic links are second class citizens (they require special > privileges and there is a distinction between link targets being files or > directories). Hard links work well. To clarify: symbolic links do not exist in Windows Vista and earlier. (There exists a concept called Junction points, but it has subtly different semantics than symbolic links, different enough that we cannot emulate symbolic links via Junctions). Windows 7 and later do have symbolic links, but they require elevated privileges to be created, as Hannes pointed out. Since Windows 10 version 1703 (Creators Update), enabling Developer Mode will disable this restriction and allow creating symlinks without UAC elevation. See https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/ for details. In Git for Windows, I originally missed the memo and forgot to add support for the special flag, but since Git for Windows v2.13.1, users can create symbolic links without administrators' privileges on Windows 10 (Creators Update or later) in Developer Mode. Of course, we still support Windows all the way back to Vista, so the default is still: no symbolic links. Thanks for your attention, Dscho
