I need share to share certain files between different projects. Thus I have a file structure like so:
D:\shared\
D:\shared\files-shared-by-all-projects-here
D:\project1\
D:\project1\project1-specific-files-here
D:\project1\shared <- directory junction to D:\shared
D:\project2\
D:\project2\project2-specific-files-here
D:\project2\shared <- directory junction to D:\shared
I have setup GIT repos in D:\project1
and D:\project2
My problem is that GIT seems to only track files in non-junctioned (i.e. real directories).
I use Visual Studio 2015 for both projects, and it's Team Explorer would behave very strangely when project has files from "junctioned" directories:
Explicitly adding files that reside in the shared directory (i.e. referencing it via D:\project2\shared\some-shared-file
) from outside of Visual Studio using Tortoise GIT for example does not work: add fails with a message that it is both a file and a directory.
The above was done with a new test project where frame
directory residing in project's root is really a junction.
In my actual projects however the situation is slightly different... If I browse the repo using Tortoise GIT for example it would actually show the shared files residing in junctions as being tracked and checked-in and part of the repo. However as soon as I open the project in Visual Studio, it would show though same files in Solution Explorer and Team Explorer Changes as "pending delete". So is this a VS quirck?
So the bottom line is I just want to know how can I make files residing in directory junctions to be viewed as part of the project on par with regular files, so that they are properly checked out and checked back in and form part of project's (repo's) history?
At present, this is not supported. This is due to a difference in interpretation between junction handling between Git for Windows and libgit2, which is the Git library that is used by Visual Studio and (parts of) TortoiseGit.
It has been decided that both implementations should treat junction points as if they are Unix mount points, however neither implementation actually does that at present.
At present, Git for Windows treats them as if they were normal directories (and so it may delete your junction and replace it with a new directory). libgit2 treats this like a symbolic link, and as a result, Visual Studio refuses to deal with it at all.
Since Microsoft will need to update Visual Studio to fix this, please file a bug at Microsoft Connect and encourage people to vote for it in the hopes that it will get fixed in VS 2015.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With