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:
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.