EDIT: this is a known issues and will not be "fixed"

The question then is how do I configure git to name the .git folder something else for this one repo.

I don't want to use the GIT_DIR environment variable as that would be a system wide.

We are evaluating Azure DevOps (using git) and I'd like to use an existing project which is currently under on-prem TFS.

I'm perfectly comfortable using git from the cli, but VS2017 automatically defaults to using the Git source control provider. If I change it back to TFS, it warns me and closes the solution. when I re-open it, I'm back to the GIT source control provider.

Short of uninstalling the git source control provider, are there any other options?

I've surmised that if VS sees a folder, even an empty one, named .git it uses the GIT provider. Is it possible to configure git to use a different folder in place of .git?

We went in circles with what seems to be a nearly identical instance of this issue: A VS installation that has GIT as a SCC provider installed by default, but must use TFS (AzureDevOps) source control.

Our situation involved opening a solution that was bound to TFS, but VS 2022 would insist on shifting the solution into GIT, even though it had no mappings to GIT, no hidden ".git" folder, nothing indicating VS should even be trying to use GIT.

Then we made a realization: The local TFS workspace mapping (eg C:\Users\username\repos\TFS) was in the same location as the default GIT repository location (eg C:\users\username\repos). Any solution or project within the GIT repo source then caused the GIT provider within VS to "kick in" and control the solution. We'd see "GIT" in the VS menu and no trick we tried would ever associate it back to TFS.

The solution: We moved the folder structure on the local device that was taken from the Workspace TFS mapping into an entirely different local folder (Eg c:\TFS) completely outside the default GIT repo location. We then updated the workspace/Source Control mapping to point to the new location, and VS then honored the TFS source control mappings. The issue of VS trying to "shoehorn" a TFS-hosted solution into Git was resolved.

This was an infuriatingly difficult thing to track down. As this problem in varying forms has made several MS Dev forums and varying SO posts, I opted to post our fix here and hope it offers a solution for others facing the same or similar situation.