Edward Thomson

The Git Contributor Summit

February 5, 2017  •  5:20 PM

The annual Git Merge conference just wrapped up, and it was another exciting year. As always, the speakers were excellent, the training was informative, and the after-party was a blast. But my favorite part was a part of Git Merge that most people don't see: the Git Contributor Summit.

The Git Contributor Summit is held in conjunction with Git Merge, and it allows the people who work on the git project, and related projects like libgit2 and jgit, to get together and talk shop.

The most important part of the Git Contributor Summit, I think, is the face-to-face time that it enables. This is a rare pleasure for most of us; the git contributors tend to chat on the mailing list, the libgit2 contributors talk in GitHub issues or in our Slack room, and the jgit contributors… well, I don't contribute to jgit, but I assume they have all the same problems that the rest of us do where we start to lack the personal touch.

And the personal touch is critical. When I first started working on the libgit2 project, I suggested bringing in some dependency on another project… and the maintainer wasn't enthused by this idea. In fact, he hated it. He hated the idea so much that he threatened to fly to the United States and murder my family if I actually merged that change.

Needless to say: we didn't really get off on the right foot.

But not too long after that, we met at a Contributor Summit and I discovered that he's actually a lovely, friendly person… he just happens to have a bit of an odd sense of humor. And so I knew that the next time he threatened to murder my family that he was just kidding.

Of course, it's not all just social time. Jeff King is part of the team of three maintainers who see to the actual business of the git project and he kicks off the contributor summit with that business. He catches us up on the health of the project as an entity and its budgetary and legal concerns.

But primarily we talk about the technical issues around git: the problems we have, and how we intend to fix them. Often these are discussions about scaling git in various directions, but we also talk about making git easier to use and, perhaps more importantly, easier to contribute to.

The amazing part about this is that we do this working together, despite having different interests and different needs. There are employees from git hosting companies, hackers who work on git in their spare time, and people who maintain git in their organization, whether that's a school, a small website or one of the world's largest news organizations.

And the hosting companies like GitHub, GitLab, Atlassian, and Microsoft all sit down together to talk about the problems they have in common and the ways they've each solved them, and they do it politely and without a hint of competition. There's no bragging about success or laughing at failures, just working together for the benefit of all our users.

It's an honor to be able to sit down with all the Git Contributors and work together on these solutions, and something I look forward to every year. Thanks so much to the organizers of Git Merge, and to the organizers and attendees of the Git Contributor Summit, for making it happen.

Goodbye, Microsoft

December 3, 2015  •  10:33 AM

Six years ago, Microsoft bought the tiny company that I worked for and moved five of us out of a cornfield in Central Illinois and into the largest software company in the world. In that time, I've done some unlikely things like hack on obscure Unix systems, write a bunch of GPL-licensed code and helped bring distributed version control into Microsoft.

But after six years, I've decided that it's time for a change. Yesterday was my last day at Microsoft, and I'll be starting a new position at GitHub in the new year.

Microsoft was great fun and I learned so much. I worked with so many great people and I'm sad to be leaving. But I'm also very happy that my friends and family will stop asking me why they can't run their old games on Windows 10 and what kind of monsters are we? And, of course, I'm also nervously excited for the next chapter in my career.

Authenticating Git clients to TFS using Kerberos

November 14, 2015  •  10:56 AM

You can authenticate to correctly configured instances of Visual Studio Team Foundation Server by using Kerberos over the Negotiate (SPNEGO) protocol. By using authentication with a Kerberos ticket, you can more securely authenticate from supported clients to your server without providing your password. After you obtain a Kerberos ticket, you can configure your git client to use Kerberos.

Configure Team Foundation Server to accept Kerberos Tickets

Team Foundation Server accepts only NTLM credentials by default, however it may be configured to accept Kerberos authentication. Access the Team Foundation Server Configuration Center by launching Team Foundation Server Administration Console.

Required Permissions
You must be a member of the Administrators security group on the server on which you will configure TFS.

To configure Team Foundation Server to accept Kerberos Tickets:

  1. In the Team Foundation Server Administration Console, select the Application Tier settings.
  2. On the Application Tier settings, select Authentication Settings.

    Application Tier Settings Dialog

  3. In the Authentication Settings dialog box, select Kerberos. This will enable both Kerberos and NTLM authentication.

    Authentication Settings Dialog

Configure the correct service principal name (SPN) for your server

A service principal name links the Active Directory service account running your Team Foundation Server instance to the service itself, and is required for Kerberos authentication to your Team Foundation Server.

Required Permissions
You must be a member of the Domain Administrators or Enterprise Administrators security group, or have been delegated the Validated Write to Service Principal Name permission, on the server on which you will configure an SPN.

You should configure an SPN for the fully-qualified domain name as well as the short name of the machine. If your server name is servername.contoso.com, you should configure an SPN for HTTP/servername and HTTP/servername.contoso.com.

If your Team Foundation Server Application Tiers are configured to use a network service account then you must configure an SPN for the computer account. For example:

setspn -c -S HTTP/servername SERVERNAME$
setspn -c -S HTTP/servername.contoso.com SERVERNAME$

If your Team Foundation Server Application Tiers are configured to use a domain account then you must configure an SPN for the domain account instead. If the application tiers are configured to run as CONTOSO\tfsuser for example:

setspn -c -S HTTP/servername CONTOSO\tfsuser
setspn -c -S HTTP/servername.mycompany.com CONTOSO\tfsuser

For more information, see the https://technet.microsoft.com/en-us/library/cc731241(WS.10).aspx on Microsoft TechNet.

Authenticate to Team Foundation Server Using Git

Ensure that you have a Kerberos Ticket Granting Ticket (TGT) for your user principal. If you log in to the computer using your Kerberos credentials, this may be done for you. If not, you may perform this manually using the kinit command and providing your Active Directory domain credentials, specifying the Active Directory domain as its DNS name. For example, the user CONTOSO\testuser should be specified as testuser@CONTOSO.COM:

kinit testuser@CONTOSO.COM

You can verify that you have a TGT using the klist command. You should see a “default principal” specified as testuser@CONTOSO.COM.

Finally, you may use the git tool with a Team Foundation Server remote repository. To indicate to git that it should authenticate with your Kerberos credentials, enter an empty username and password. For example, to clone a repository named “Test”:

git clone http://servername.contoso.com:8080/tfs/DefaultCollection/Test

And simply press Enter when prompted for your username and password.


  1. Ensure that your Team Foundation Server accepts Kerberos credentials. Use a network monitoring tool such as Wireshark or Fiddler to examine a successful connection from Visual Studio to Team Foundation Server. If the connection uses NTLM authentication instead of Kerberos, examine your server configuration.

  2. Ensure that your git client was compiled with the Kerberos system libraries. Use a network monitoring tool to examine an unsuccessful connection from git to TFS. If the connection does not attempt to use Kerberos, contact your operating system vendor for assistance.

Setting Files Executable in Git on Windows

June 9, 2015  •  11:36 AM

Sometimes you need to check an executable into your Git repository and - even though Windows doesn't really have a concept of an "executable bit" - you might need to set it executable for the other platforms.

For example, a handful of my native code projects use the very clever clar project for unit testing. Clar uses a Python script to introspect your unit tests for the actual test functions and generate the harness. It's handy if this generator is executable on Unix boxes and - thankfully - Git will let you set it executable even on a Windows box.

Once you've staged your file, you can set it executable with the git-update-index --chmod=+x command. For example:

C:\Repo> git add generate.py
C:\Repo> git update-index --chmod=+x

And now you can ensure that the file is executable by inspecting the index:

C:\Repo> git ls-files --stage
100755 587efb519c0ab60692e8d4c19f3471e0dbbecd3d 0       generate.py

If you're familiar with Unix permissions, then you'll note that first column looks like a Unix permission. Indeed, coming from a nice Unix heritage, Git uses the mode 100644 to represent a non-executable file and 100755 to represent an executable file.1

Now when you commit this change and check it out on a Unix system, generate.py will be set executable!

  1. Note, however, that this only looks a lot like a Unix permission. Regardless of the file's actual permission, Git only stores 100644 for regular files and 100755 for executable files. Effectively, this only stores whether a file is executable or not.

Pull Requests in Visual Studio Online are great way to perform code reviews. But if you like reviewing code in your favorite editor, instead of on the web, they can be frustrating. Fortunately, you can set up git to fetch pull requests from Visual Studio Online.

Visual Studio Online creates branches for pull requests in the refs/pull/* namespace, which is not fetched in a default configuration. To set up your git client to fetch them, simply run:

git config --add remote.origin.fetch +refs/pull/*/merge:refs/remotes/origin/pr/*

Now on your next git fetch, you will download the pull requests, and you can simply check out the one you're interested in:

git checkout pr/20804