3 ms·

I had success porting our ancient TFS repository to git while preserving history with git-tfs https://github.com/git-tfs/git-tfs https://github.com/git-tfs/git-

I had success porting our ancient TFS repository to git while preserving history with git-tfs https://github.com/git-tfs/git-tfs https://github.com/git-tfs/git-tfs If you have many years of history, it will take a long time to import, so you may want to try getting the history of a subdirectory first. The team, which was unfamiliar with git up until that point, was very happy with it. Unfortunately the Git integration in Visual Studio was/is pretty terrible -- it did not even support git stash until VS 2019 (which I'm not using yet). So try to have your teammates learn the command line workflow first. Those who used only the VS GUI had a lot of trouble. Also, doing git operations in the IDE sucks because it will constantly reload the project. This is true of TFVC as well, but you can avoid it with an external git client.

Someone1234 7y ago
Thanks I'll check it out.
SOLAR_FIELDS 7y ago
I am quite interested in who uses Git GUI’s vs the command line tool (and which tools they use if GUI). Command line is going to be more robust but given the difficulty in learning Git (I end up teaching people much more senior than me some of the tricks) I can imagine that more people use the GUI than I would initially think. I’ve found GUI’s only to be useful in one or two specific examples: complicated rebases and merge conflicts. In all other cases the CLI workflow seems faster.
- sempron64 7y ago
  A significant portion (30-50%) of the team mostly use the Visual Studio integration and are happy, it's not too different from their previous workflow. The merge conflict experience is not too bad as you get the nice integrated conflict editor. The real issue managing committed but locally-modifiable config files. De-indexing is not a good option because once they're de-indexed there's no way to manually add them in Visual Studio, and I don't want to force everyone to open the CLI to run git add. Most of our developers continually stash these files. This means staging and committing is a painful process. I hate that I can't git commit -a as well... Those who write javascript and use Visual Studio Code mostly use the CLI now in the integrated terminal (they are very happy to not have to open up VS to commit). Deployment engineers who don't use Visual Studio often and some other teams who started using Git earlier prefer Atlassian Source Tree.

Someone1234 7y ago

Thanks I'll check it out.

SOLAR_FIELDS 7y ago

I am quite interested in who uses Git GUI’s vs the command line tool (and which tools they use if GUI). Command line is going to be more robust but given the difficulty in learning Git (I end up teaching people much more senior than me some of the tricks) I can imagine that more people use the GUI than I would initially think. I’ve found GUI’s only to be useful in one or two specific examples: complicated rebases and merge conflicts. In all other cases the CLI workflow seems faster.

sempron64 7y ago
A significant portion (30-50%) of the team mostly use the Visual Studio integration and are happy, it's not too different from their previous workflow. The merge conflict experience is not too bad as you get the nice integrated conflict editor. The real issue managing committed but locally-modifiable config files. De-indexing is not a good option because once they're de-indexed there's no way to manually add them in Visual Studio, and I don't want to force everyone to open the CLI to run git add. Most of our developers continually stash these files. This means staging and committing is a painful process. I hate that I can't git commit -a as well... Those who write javascript and use Visual Studio Code mostly use the CLI now in the integrated terminal (they are very happy to not have to open up VS to commit). Deployment engineers who don't use Visual Studio often and some other teams who started using Git earlier prefer Atlassian Source Tree.