Add symlink file as file using Git on Windows

The current answer(s) are out-of-date and require revision given recent changes.
The solutions given there isn't enough and isn't working.

There are still issues with the latest Git 2.12 on Windows (February 2017, 18 months after the OP's question)

In the context of working on what was called git-new-workdir in 2015 (the ability, form one clone, to have multiple working tree: this ended up being called git worktree), the Git developers were asking how to reference those worktrees from the main cloned repo.
Would they be using ln? or its Windows equivalent mklink?

This thread, at the time, highlighted the issues:

When running on Windows in MinGW, creating symbolic links via ln always failed.
Using mklink instead of ln is the recommended method of creating links on Windows

That might be true, but not ideal: "Git Bash Shell fails to create symbolic links" does mention:

For my setup, that is Git for Windows 2.11.0 installed on Windows 8.1 export MSYS=winsymlinks:nativestrict does the trick as explained here: git-for-windows/pull/156

It's important to launch the Git Bash shell as administrator as on Windows only administrators could create the symbolic links. So, in order to make tar -xf work and create the required symlinks:

  • Run Git Bash shell as an administrator
  • Run export MSYS=winsymlinks:nativestrict
  • Run tar

See also "Git Symlinks in Windows", where the setup now (Git for Windows 2.10+) include symlink support:

symlink supoprt

You need to specify that during the clone:

git clone -c core.symlinks=true <URL> 

And your CMD session needs to be run as admin.

Needless to say imposing that prerequisite on Windows users is a no-go (Windows in enterprise generally come with limited or no privilege elevation)

Yet, PR 156 does represent some Windows support for symlink, released in Git For Windows 2.10 (Sept. 2016).


It is telling that git worktree ended up implementing the multiple working tree reference... by not relying on symbolic links and by making the borrowee and borrowers aware of each other.

When you are done with a linked working tree you can simply delete it. The working tree's administrative files in the repository will eventually be removed automatically (see gc.pruneworktreesexpire in git config), or you can run git worktree prune in the main or any linked working tree to clean up any stale administrative files.

So no symbolic link there.


If adding symlinks to the index fails with error error: readlink("..."): Function not implemented, try to find this line in the local or global config:

[core]
    symlinks = false

You need to set symlinks = true for a successful push. Default value (=true) if parameter does not exist or is not working correctly and it depends on the settings with which the repository was created.

Hardlinks do not work with GIT, as the file and hardlink are stored as separate files.

It works the same with git version 2.8 or above (I did not check versions less than 2.8)