@pleriche Also thanks from my side for the Wiki entry.
As I see it, we have 3 options to fix this:
1) Completely remove Symlinks in favor of Hardlinks form the installer.
2) Add a command line option to the installer ("/nosymlinks") to force falling back to Hardlinks.
3) Always hardlink upload-pack and receive-pack as Dscho suggested.
While 2) is a flexible solution, its drawback is that is has to be documented. I don't like 3) as it adds magic to the installer. Both 2) and 3) slightly increase the installer's complexity. So I'd vote for 1) as it
a) removes complexity from the installer,
b) Symlinks can be created by Admins only,
c) Symlinks have very limited advantages over Hardlinks in our case.
@dscho I've submitted a pull request for the updated install.iss that creates hard links for git-receive-pack and git-upload-pack. I've tested it and it works.
@sschuberth Switching to hard links will solve the problem too, so either way I will be happy.
IIRC the original reasoning for using symlinks was that most backup software is stupid and does not realize when files are hardlinked...
So I'd like to submit
4) hard-link receive-pack and upload-pack as required for the remote side of pushing/fetching, but remove all other hard-linked .exe files, keeping only git.exe.
If you're considering removing all the other symbolic/hard links, then very few files remain in the libexec/git-core folder and it begs the question: Why not just move the remaining files into /bin and do away with libexec/git-core? None of the installer options adds libexec/git-core to the path, so I would assume the executables in there are the less frequently used ones and moving them will probably not cause major disruption for most users.
With everything in /bin you could get away with just a single hard link (or even just a plain copy of git.exe) for git-receive-pack.exe. Git-upload-pack.exe is already a standalone executable, but since it currently resides in libexec/git-core it is not on the path.
@pleriche usually I would agree with doing away the libexec/git-core/ directory. But that is a decision we would have to get accepted upstream, chances for which I estimate to be very close to 0. So while I agree with you, pragmatically we'll probably have to keep it.
Fixed in da509c407c83f7ab781db10b895652f2108f506f by not trying to create Symbolic Links anymore, effectively falling back to Hardlinks. Dscho's suggestion number 4) may be additionally implemented in a future commit.
