Answered Team Explorer loses connection with git repository

[Gerald Christian]

Once in a while my Team Explorer in VS 2019, after re-opening the project, has lost connection with the git repository.

This means that the project is listed under Team Explorer but there are no options for Changes, Branches and so on.

Right-clicking the project gives me the menu options "OpenP, "Open in File Explorer", and "Open Command Prompt". The "Remove" option is grayed out.

The git repository and the C# .NET project is the same folder - e.g. the git working tree is the C# .NET project directory.

The only way around this appears to to close the project and re-clone it. But then I lose all my bookmarks from the project.

My work-around for now is to abandon Team Explorer and go back to using Egit with another IDE to maintain my git repository.

Is there a way to recover from this without re-cloning the project?

 

[Gerald Christian]

The git repository itself is fine through all of this. Team Explorer is unable to read it's commits and unable to show changes or history of any kind.

I am looking for a way to renew that connection with the same repository, and not have to re-clone the repository in order for Team Explorer to see it.

Team Explorer is an excellent and simple to use git user interface, one of the best I have used.

 

[Skydiver]

Are you working alone, or with a team? If you are working with a team, did someone accidentally check in the .vs directory or any of the hidden files that VS uses to maintain per user state? (E.g. someone either didn't start of with the default VS generated .gitignore file or made one of the rules in the .gitignore file too promiscuous)

 

[Gerald Christian]

I am working alone. I use git to maintain different versions of this project and for keeping parallel branches of development.

Could there be a conflict caused by pushing a commit using Egit for example ?

In any case is there a way to "reconnect" Team Explorer to the *existing* repository, rather than have to clone it and open it as a new project?

 

[Gerald Christian]

I did find the following in the .gitignore file:

.vs/MyApplication/v15/Server/sqlite3/db.lock
.vs/MyApplication/v15/Server/sqlite3/storage.ide
.vs/MyApplication/v15/Server/sqlite3/storage.ide-shm
.vs/MyApplication/v15/Server/sqlite3/storage.ide-wal
.vs/MyApplication/v15/sqlite3/db.lock
.vs/MyApplication/v15/sqlite3/storage.ide-shm
.vs/MyApplication/v15/sqlite3/storage.ide-wal
.vs
/.vs

That is just an excerpt of the file, the parts related to .vs.

 

[Skydiver]

You should actually be ignoring:

.vs/

e.g. The .vs directory and all its children. You don't need to explicitly list each of the files under the .vs directory tree.

As for "reconnecting" the Team Explorer, you'll need to diagnose exactly what is causing it to get disconnected in the first place. My gut feel is that one of the VS local per user settings files is getting overwritten by syncing with your git repository, and hence my suggestion earlier about ensuring that nothing in the directory related to local state is checked in. That means these should also be in your .gitignore:

# User-specific files
*.suo
*.user
*.userosscache
*.sln.docstates

# User-specific files (MonoDevelop/Xamarin Studio)
*.userprefs

# Visual Studio cache files
# files ending in .cache can be ignored
*.[Cc]ache
# but keep track of directories ending in .cache
!*.[Cc]ache/

 

[Gerald Christian]

Ok perfect I will try that.

 

[Gerald Christian]

I did find a way to "reconnect" Team Explorer with the git repository.

Clone the troublesome repository to a new one, which as I noted above will now be missing the bookmarks of the original project.

But then discard the clone repository (I moved it to another folder), and continue to use the cloned (original) repository.

Team Explorer is now properly displaying the original repository with the proper Branches, Changes, and other menu items.

And because we are using the original project we still have our bookmarks.

It seems like the act of cloning the repository cleans up some issue in the project files and resets Team Explorer into normal operation.

This is more of a work-around than a proper fix but at least now I can continue to use Team Explorer.

I will continue to use the correct .gitignore settings as advised above,.