Error 400 when cloning TFS Git repo using Visual Studio 2017
Solution 1
UPDATE: It does appear that Microsoft has fixed this issue in an update to Visual Studio 2017. Most likely, Update 3 as mentioned in comment below. If you're not using at least Update 3, this answer may pertain to you still, as people were reporting this issue even with version 15.8.5.
This is primarily because Visual Studio 2017 is mishandling spaces in the Team Project Collection name. It does not encode them to use %20 for spaces. Here's steps to work around.
Click Cancel button to close the "Connect to a Project" window.
In Team Explorer, underneath the Clone Repository section, notice how the top box does have spaces in the URL. Cancel the clone by clicking the Cancel link. Do this, because you'll find that you cannot edit the Clone Repository inputs.
Then, click the Clone Repository link in the Project section of the Team Explorer window.
You'll notice the Clone Repository section will reappear, but now will not be editable. Notice that the first/top input box has replaced any spaces in the URL with %20. Ensure that you're second box, which maps a local path to download your source to, is accurate. Click Clone button, and it should work.
Solution 2
I can confirm it is still (or again) broken in version 15.8.1.
But I found another workaround:
- use a browser to navigate to the 'Code' repository in vsts
- click on the 'Clone' button (icon)
- select IDE 'Clone in Visual Studio'
- allow the link to open VS 2017 and it will pass along the correct url encoded location
Solution 3
I encoutered this issue again now, year after fix was released, in VS 15.6.6. Enterprise. When trying to connect to a project with space in the name, VS kept messing up the URL and therefore didn't find the project.
Steve Kennedy's solution is no longer possible - MS actually fixed that \O/.
In the end I copied complete working project from a collegue so that I'd get configs with correct URL. Everything worked fine.
Just so you know, there is this solution as well.
Related videos on Youtube
Steve Kennedy
I started writing software in 1996 using Turbo Pascal and Delphi. I’m passionate about good software design practices, and have an affinity for simplicity in architecture. Now, I enjoy keeping up with the latest and greatest Microsoft technologies. I believe in giving back to my community, and continuous learning. I enjoy spending time with my family - it’s my number one priority. Lately, I’ve been pretty high on Ionic application development.
Updated on June 04, 2022Comments
-
Steve Kennedy almost 2 years
In Visual Studio 2017, when I attempt to connect to an existing on-premise TFS 2015 team project, and attempt to clone an existing Git repo using Team Explorer (by clicking the Clone button after highlighting the the repo name in the Connect to a Project modal), I get error message saying
Git failed with a fatal error. fatal: unable to access 'https://servername:8080/tfs/Team Projects Collection/ProjectName/_git/RepoName/': The requested URL returned error: 400
I also get this error showing up in my output window.
-
smalltowndev about 7 yearsThis solution is totally right and it just fixed my VS2017 git issues, thank you!
-
spottedmahn over 6 yearssupposedly fixed in update 3: developercommunity.visualstudio.com/content/problem/37711/…
-
RationalGaze over 5 yearsGreat solution, this helped me. I have the latest version of VS 2017 and this issue has not been fixed as Microsoft says and/or the bug has been re-introduced.
-
Carl Heinrich Hancke over 5 yearsCan confirm this bug is still present in 15.8.3 but that the above workaround works.
-
David Conlisk over 5 yearsAlso present in 15.8.5 and this workaround still works.
-
Jan Bludau over 5 yearsAlso present in 15.8.6 and this workaround still works
-
user1867382 over 5 yearsNote that if you have VS Code installed, that is the default dropdown selection. Change to Visual Studio for VS checkout. Thanks for the workaround!
-
Greg over 5 yearsAlso present in 15.8.7 and this workaround still works.
-
Tim over 5 yearsI just upgraded to 15.8.8 and this issue is still present (the accepted workaround no longer works), but this workaround still works.
-
Michael Kintscher they-them over 5 yearsI just upgraded to 15.8.9... same comment as Tim. Accepted work around does not work, but this workaround still works.
-
TheNerdyNerd over 5 yearsNot editable for me but the other item works perfectly.