Making Visual Studio 2019 see the git repo present in source but not in the build dir (which has the sln file)

Viewed 408

I'm working on an existing, large open-source project that doesn't like in-source-tree builds. So its cmake-generated .sln file is placed in the build dir that has no .git anywhere in its parent directories because that .git is in the disjoint source tree.

\build
  \proj.sln
\src
  \.git

How do I make Visual Studio 2019 still see these "sideways" .git files? It can see the (C++ etc.) sources referred in the sln, of course, but nothing relating to git works inside VS2019 in this setup, by default.

enter image description here

I'm guessing I could mess with GIT_DISCOVERY_ACROSS_FILESYSTEM but I'm not sure it that would work with the way VS does git.

(And yes, the src dir is a git-cloned repo. I've made commits in it etc., but from the command line.)

And if I F1 (for help) the "Git Global Settings" in VS 2019... it goes to an oops page so that isn't exactly helpful. Ok, I found the actual VS doc/help for git. But it doesn't really answer my question.

If instead of opening the sln file, I open the directory of the source (src) from VS, then VS sees the git repo ok (current branch and what not) ... but I can't build anything, because VS can't see/find the sln file in this context. So, how do I "have my cake and eat it", i.e. have VS see the git stuff and allow me to build?

2 Answers

I've made VS see the git repo (from within the sln) by manually adding a .git file in the build directory with just this contents:

gitdir: X:/full-path-to-repo/.git/worktrees/src

I had forgotten to mention that the src was also a worktree, but that probably didn't make a diff (they also have .git file).

Unlike the GIT_DIR environment variable, this .git-file method of telling where there repo is, isn't ignored by VS's git implementation.

But there's a big problem with this (too)! VS now thinks it should add all those build object files to the repo! It thinks there are some 4,000 A-type changes :-( So, for this to be a real solution, I'd also need to able to tell it not do that somehow. (This might be ok for a smaller project, but writing filters for all those cmake-made files is going to be challenge in my case...)

enter image description here

enter image description here


Also, for an alternative approach if I install the cmake workload in VS and open the source folder again (instead of the sln), VS makes a big mess by immediately trying to do an in-source build (in an src\out subdir it created), and with completely wrong, auto-generated settings, like using Ninja for some reason when this project doesn't use it at all. (I suspect it did this because it could not find the out-of-source build dir, which had the right cmake cache.)

enter image description here

So it seems there are "miles to go" for VS to be fully useable with cmake projects like this, meaning that use out-of-source-tree build dirs. Apparently nothing really changed in the MS cmake approach in 8 years:

  • It works in the context of Visual Studio’s new “Open Folder” feature rather than their established project/solution workspace. So you will have to learn the new environment.
  • There are additional settings files to override CMake configuration which will be a source of duplication and confusion.
  • It used the Ninja build system by default. To change it to VS projects, you have to adjust it in a settings file.
  • To launch the debugger for startup executable, you have to introduce a launch file.

For testing, try and launch Visual Studio from a CMD where you type first:

set GIT_DIR=C:\path\to\.git
cd C:\path\to\proj
.\proj.sln

(assuming the .sln extension is associated with devenv.exe)

Related