Add symlink file as file using Git on Windows - windows

Question

I have a big (more than 1000 files) VS C# project in git. I need to create a small demo project and use ten files from the big project. To create this new project, I added ten files with mklink (symlink) from the big project to the small. All changes in corresponding files in the big and small project are identical. Now I need to add the small project to a different (my own) git repo.
But symlink will not add in git :
(error: readlink("X.cs"): Function not implemented)
How to add the X.cs (symlink) file in git as a regular file?
I need all changes in X.cs (in big project) to be moved to X.cs (small project).

Answer 1

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)

Answer 2

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.

Answer 3

git has problems with individual file links but it has no problem with directory symbolic links(mklink /d ). Therefore move your image files to another directory in your big project and create directory link in your git repo to this directory.
See below for example.
P:\denemeler\gitdeneme1>mklink /d linkDirectory P:\puzzles
Created symbolic link : linkDirectory <<===>> P:\puzzles
P:\denemeler\gitdeneme1>git status
On branch master Untracked files:
(use "git add ..." to include in what will be committed)
linkDirectory/
nothing added to commit but untracked files present (use "git add" to
track)
P:\denemeler\gitdeneme1>git add linkDirectory
P:\denemeler\gitdeneme1>git status
On branch master Changes to be
committed: (use "git reset HEAD ..." to unstage)
new file: linkDirectory/Juggle Fest Question.txt
new file: linkDirectory/jugglefest.txt
new file: linkDirectory/triangle.txt
new file: linkDirectory/triangleQuestion.txt
P:\denemeler\gitdeneme1>git commit -m "new files"
[master 0c7d126] new
files 4 files changed, 14150 insertions(+) create mode 100644
linkDirectory/Juggle Fest Question.txt create mode 100644
linkDirectory/jugglefest.txt create mode 100644
linkDirectory/triangle.txt create mode 100644
linkDirectory/triangleQuestion.txt
P:\denemeler\gitdeneme1>echo "aa" > p:\puzzles\newFile.txt
P:\denemeler\gitdeneme1>git status
On branch master Untracked files:
(use "git add ..." to include in what will be committed)
linkDirectory/newFile.txt
nothing added to commit but untracked files present (use "git add" to
track)

Answer 4

Git does indeed have trouble with symlinks on Windows. However, I don't think you even need symlinks for your problem. A simple workaround is to write a small *.bat script to copy the files in question from one repository to another on demand. With symlink, you don't need to run a script, which saves you a few seconds, but you get a problem that you can accidentally change file in small repository and have unwanted modification in big repository.

Answer 5

Looks like all your simlinks located in one ntfs partition, if it is true, you can renew all simlinks to hardlinks, by some script with command, mklink /h...
Hardlinks friendly for any CVS.