Juri Strumpflohner Follow Juri is a full stack developer and tech lead with a special passion for the web and frontend development. He creates online videos for Egghead.io, writes articles on his blog and for tech magazines, speaks at conferences and holds training workshops. Juri is also a recognized Google Developer Expert in Web Technologies

git tf - An Early View

Aug 23, 2012 2 min read

I really like git. I actually don't know exactly why. I guess it's mainly also because GitHub is such a nice platform and probably because git is extremely fast and compresses the source code nicely. Anyway, after announcing git support on Codeplex this year, Microsoft decided to develop a git client that allows to work with plain normal TFS repositories. So lets take a quick look at it.

It's git tf, a nice little command-line extension (btw written in Java) that allows you to git clone a TFS repository and then work like you're accustomed to work with git locally before then again submitting your changes to the central TFS repo. Even more, it is possible for people to work "mixed", meaning that some team members might use git while others in the same team might just normally use TFS as till now.

To get started, you'll need to have Git installed and configured and then you need to download the latest git-tf release from Codeplex.

To then clone your existing TFS repo execute

git tf clone http://yourtfsserver/tfs $/path/to/your/project

you then make and commit your local changes just normally and finally you push everything again to the server executing a

git tf checkin

When doing so I got an error message saying something like "Couldn't lock $/...." and it is because git tf tries to lock the root folder, basically the folder on TFS which you previously cloned with git. There reason for doing so is described in this work item here.

For this to work correctly your 20 commits need to be checkin in sequentially in Tfs in order. So if we do not have lock in place and we start checking in the first changeset, then the second and another user (user2) while checking in your commits decided they want to checkin too .. what will happen is that the other user's checkin will be inserted in between your commits and thus the history in TFS does not reflect the true history any more because the changeset of User2 was checked in between your changes. Having locks ensures that the TFS history is correct always when operating in deep mode.

Apparently adding --no-lock option like

git tf --no-lock checkin

I'm not yet 100% sure what effect this might have. Might this screw up my history?? Bo, I'll do some experiments and see what happens.

In the mean time I've written down a tutorial-like page on how to get started where I'll add further things while experimenting with git-tf. Check it out here.

Questions? Thoughts? Hit me up on Twitter