Reported by Matt Griffiths Feb 20, 2017 at 01:56 PM windows 10.0 visual studio 2017 rc git. Within Manage Connections > Connect to Project. Selecting a previously cloned (existing local) repo asks me to clone the repo again. Even after removing the current local repo and doing the clone again, it still asks. On Mac, all the installation files points to the same Visual Studio Community version which cannot connect to TFVC. So, it's impossible for a Mac user to get the first checkout of a TFVC repo. So, it's impossible for a Mac user to get the first checkout of a TFVC repo.
Free video player for mp4. Visual Studio for Mac Enterprise Edition version 7.3.3 build 23 is unable to connect to TFS 2017 remote GIT repository, the Git-CredentialManager-for-Mac is installed, git clone works perfectly from terminal, but the VS for Mac is not able to present AD credentials and keep asking to reenter credentials in a infinite loop. PS: Microsofties aka [MSFT] guys we know you have KPIs and are wish to mark ASAP the question as closed, but please it's a shame to not have VS for MAC living happy with your DEVOPS environment, please give me a plausible and reproducible solution instead close it with unproven one. We discovered this issue after buying MacBooks for the team. We are an enterprise development team that uses an on-prem TFS installation to host our Git repositories. We too can clone via the terminal, but not via VS for Mac's Version Control GUI. We are using Git via HTTPS successfully everywhere else (Windows, VS2017 for Windows, Mac, etc.).
I agree, with the OP- this shouldn't be another fallen soldier via 'We have decided that this issue isn't important as it doesn't affect enough people'. This is a basic function of Visual Studio- and we need this to work since nobody has given us a legit Team Explorer for VS for Mac. Not to mention the fact that this should be cake to fix! Hook it up my Microsoft brothers!
I've tried to get VSTS to connect to our enterprise Git repository. To do this I had to get our firewall opened up, and as a result we found that VSTS does not connect to our network using the VSTS domain, ie ########.visualstudio.com Instead it connects using the IP address of the build agent, which is in the range specified in the Azure Public IP list. We could free up our firewall to all the Azure Public IP's, but this is very fragile (they can/will change), and presents a significant security risk as anyone using Azure could attempt to connect to our Git repository. Interestingly, if you install a private build agent, then VSTS connects to this using the VSTS domain, we have observed this.