Mac – Install Xcode for git?!

It is so lame that I have to install Xcode to get git to work on the command line. I did’t have this problem last time I used git, but I just a few days ago upgraded to Sierra and I received this message while trying to clone a repository from GitHub.

git clone error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

Aaaand, lame. I don’t think I’ve ever read a really long license agreement via a terminal window, btw. That was a thing to behold.

That said, once I installed the tools, Xcode reqs, everything was peachy and worked fine.

Here’s to doing that in the shell:

xcode-select --install

Or if you already have Xcode

xcode-select --reset

Yep, I’m in Mac all the way now. Instead of griping about MSFT tools, I get to gripe about other tools 🙂 Stay tuned.

rake, psake, grunt, gulp, jake, make, cake, brunch, ant, bash, maven, or fabric. as long as you putOnAHelmet

A standard task I began placing in my projects lately is one that easily integrates with my build tool of choice (rake, psake, etc…) and when run, installs a git pre-commit hook into my local copy of the repo that will run tests before code is committ. I’ve fancied calling the task putOnAHelmet.

Come checkout a small little github repo I started to keep track of various versions of this and feel free to open an issue or send a pull request with another one!

I don’t want to get into details about pre-commit hooks and how you should author them in this post (maybe we can expand the language in the repo’s readme…). You can also check out other writings… But one of the biggest problems I have with them is gits in-ability to easily keep track of pre-commit hooks much like it can with the rest of the projects source.

Now it’s true that different people need the ability to customize these, but a general “running of tests” before committing is a great first step and I’ve found these set of tasks the easiest way to carry them from repo to repo.

Hope others find this useful!

Happy committing!

How do I undo a bad rebase in Git?

If you use git and leverage the rebase command, you’ve probably run across a merge issue during the rebase and if you’ve ever felt like, “man, I wish I had a ‘do-over’.

If you’re still in the middle of a rebase it’s easy to start over:

git rebase –abort

But let’s say you started with this:


Did a git rebase and are now looking at:


Except you screwed up during a merge conflict and now un-sure how you can get your ‘do-over’.


I was pleasantly surprised at how easy it was. (If you know key)

Leveraging the git reflog, you can go back in time and check out your branch as though the rebase never happened.

In the following link, I put together a set of steps to create a git repo that puts you into this position (of a bad rebase) and then describes how to get out of it.

I’d love to hear any feedback on this repo. Or try submitting a pull request or post a GitHub issue.

Happy Git’ing!

Mimicking the AppHarbor Deployment Experience

On Thursday night at NETDUG (the Boise .NET Developer User Group), I demonstrated how to get started with AppHarbor.  I also showed how to mimic the AppHarbor deployment experience.

And thanks to the generosity of the AppHarbor team, we were able to raffle off a Reflector license to one of our attendees!

Getting Started with AppHarbor

You can find many blog posts (and videos) detailing the process of getting started with AppHarbor (see below).  But the basic scenario comes down to these steps*:

  1. Installing and configuring Git. (I use msysgit and Git Extensions.)
  2. Initialize a repository for your application.
  3. Deploy your application to AppHarbor. (If you do not have an AppHarbor account yet, feel free to use this referral link.)

* If you prefer to use Mercurial, follow these steps instead.

If you develop .NET web applications and haven’t tried out AppHarbor yet, do so…Now! I did mention the service is free, right?!?

Mimicking AppHarbor Deployment

Disclaimer: The process I am about to describe is informational and not prescriptive. AppHarbor provides much more value than just deployment, and I do not want to detract from that in any way.

If you have read my previous posts, you know that I use TeamCity and Rake for my build server environment. So I thought I would try to mimic the AppHarbor experience using those tools.

In order to follow along you will need to:

  1. Install Git on your development workstation and build server
  2. Install Ruby on your build server
  3. Install TeamCity on your build server
    * If you need to learn how to install and use TeamCity, I posted a series on TeamCity 4.5.
  4. Install Web Deployment Tool 2.0 on your build server and IIS web server
  5. Start the web deployment service on your IIS web server
  6. * For the purposes of the user group presentation and this post, my development workstation, build server, and web server are all on the same machine.

We need to manually provision much of the infrastructure that would be provided for us automatically by AppHarbor, including:

  • Configure the web application in IIS
  • Set up a bare Git repository
  • Configure TeamCity to watch the bare repository (VCS Settings)
  • Use customize build scripts in TeamCity (Build runner/task)
  • Push your application to the TeamCity repository

Other tasks I will not be considering for this sample include database provisioning and custom configuration variables.

Remember, with AppHarbor, the initial provisioning takes a matter of seconds. With that, let’s get our environment ready.

Configure the web application in IIS
  1. Create a folder on your web server to store the website. (e.g., c:\sites\sample)
  2. In IIS, create a new virtual directory under the default site and set the path to the folder you just created. My virtual path is sample.
  3. Note the IIS application path. Mine is Default Web Site\sample. My url will be http://localhost/sample.
Set up the bare Git repository
  1. Create a folder to store your bare repository. This is the repository TeamCity will watch and use to get code to build. You can create the repository on the build server or on a remote server.  (e.g., c:\repos\sample.git\)
  2. Right-click the folder and run the Git Bash from the context menu
  3. In Git Bash, type git init –bare
Configure the TeamCity build configuration
  1. Create a new project (e.g., Sample)
  2. Create a new build configuration (e.g., Deploy) and name it
  3. Leave all other settings on the first page of the wizard at their default
  4. Attach a new VCS and name it
  5. Select Git as the VCS type
  6. Set the Fetch URL to the bare repository you just created (e.g., c:\repos\sample.git)
  7. Leave all other settings at their default
  8. Add a new build task
  9. Select Rake as the build runner
  10. Select Rakefile content and copy the following into the textbox (Update the site path and project names as appropriate)
  11. Leave all other settings at their default
  12. On the Build Triggering page, add a new VCS trigger to build on a VCS change.
    Whew! Now that all the infrastructure is in place, let’s do this!
Push your application to your TeamCity repository
  1. Assuming your local Git repository is set up and you’re application is ready to deploy…from Git Bash in your local repo, add your remote repository.  Given the settings described above, I would use the following command: git remote add teamcity /c/repos/sample.git
  2. Then type: git push teamcity master
  3. In less than a minute, TeamCity should start to package and deploy the website.

Using TeamCity for deployment takes markedly longer than AppHarbor. TeamCity uses a polling interval to determine if there are changes; whereas, I assume AppHarbor is using a git post-commit-hook. As an aside, if you haven’t already, start looking into the Web Deployment Tool.

Auto-provisioning and super-fast deployment on an elastic infrastructure…wish I had implemented it first. Winking smile


A bug was introduced in Visual Studio 2010 SP1 which causes an error when deploying with parameters. You may need to update your Microsoft.Web.Publishing.targets file referenced in the KB article (although I cannot confirm that this fixes the problem, yet).

Git-Tfs – Where Have You Been All My Life

My very first encounter with a version control system was CVS. I’ve used this tool for many years (late 90’s, early 2000’s), learning a lot of best practices about source control usage in the process. But there was a lot of friction as well. That is why I switched to Subversion many years ago and I’ve been pretty happy with it ever since. Sure, it has its quirks but at the very least it is a lot better than Visual SourceSafe which was an established alternative back in the days, especially in the Microsoft space.    

Fast forward a couple of years. With a few exceptions, Visual SourceSafe has been replaced with TFS Version Control in those run-of-the-mill enterprise corporations. This was quite an improvement but also a lot of the friction remained, at least in my humble opinion. Just as with Visual SourceSafe, TFS is being forced upon entire flocks of developers, mostly by management and/or non-coding architects. I still find this to be quite odd as managers never tend to use TFS themselves as this is generally considered a developer tool.

Anyway, this is usually the part where one starts writing down a five page rant against TFS. But I’m not going to. Why? Because I decided to  look for a good solution instead and holy sweet batman, I found one. A while back I decided to learn more about Git. It’s definitely not a silver bullet either but I was so impressed with all its capabilities that I moved all the code for my home projects from Subversion to Git. But the largest friction remained. I was still forced to use TFS day in and day out. But a couple of weeks ago I ran into this post from Richard Banks where he discussed a plugin for Git named git-tfs. This extension is basically a two-way bridge between TFS and Git that lets you treat TFS source control as a remote repository. The way Git works is that the entire repository is contained in a local .git folder. This way it’s able to play nicely with a TFS repository as they don’t collide.      

Setting up git-tfs is quite easy. Just download the latest version, put it in a directory and add the location to the PATH environment variable. Now you’re good to go.

To get the source from a TFS repository you have to execute the ‘git tfs clone’ command.

git tfs clone http://some_tfs_server:8080 $/some_team_project/trunk

Note that by using this command, it will fetch the entire history by retrieving all change sets. If you’re anxious to get started (as I first was 😉 ), then there’s also the ‘git tfs quick-clone’ command that will skip the history and just get the latest version.  

git tfs quick-clone http://some_tfs_server:8080 $/some_team_project/trunk

All source files that are fetched from a TFS repository are also no longer read-only, which is quite nice compared to how TFS source control does things. Now that you have all the source files, you can start by adding a .gitignore file and follow the development workflow that you would normally use with Git.

Suppose that you completed a new feature and you want to push those changes back into TFS. This can be done using the ‘git tfs shelve’ command.

git tfs shelve user_story_x

This will create a shelve set that contains the changes which you can then unshelve and check in as you would normally do with TFS source control. The latest release of git-tfs even lets you check in your source files directly without needing to shelve. This can be achieved by using the ‘git tfs ct’ command. Note that this only works for TFS 2010.  

Suppose that another developer on your team checked in some code in TFS that you want to pull into your local working copy. For this you can use the ‘git tfs pull’ command that first fetches the latest change sets and merges them with your version of the code.    

One thing that you also need to take into account are the TFS source control bindings. These are stored directly in the solution file (horrible, just horrible). When opening the solution in Visual Studio, I just choose to work offline and reestablish the bindings when I’m back in TFS.

If you’re forced to use TFS source control and you’re fed up with it, then I strongly advice you to learn more about Git, install git-tfs and be merry. Kudos to all the contributors of this wonderful open-source project. You guys are truly amazing!  

I hope this helps.

Boise Code Camp 2011–Introduction to Git

We are having another great Boise Code Camp and once again, I am glad I presented.

Git is a DVCS, or distributed version control system, that is gaining popularity in the .NET community. In this session, we will explore:

  • How Git is different from other version control systems (Subversion, Team Foundation Server, Mercurial)
  • Common tools (emphasis on Windows users)
  • Basic commands and workflow
  • Using Git as your Subversion client
  • Various Git services, such as GitHub, and AppHarbor

My slides are available on github.

If you attended the presentation, please leave your feedback at SpeakerRate (

Moving your global .gitconfig file

I am using msysgit for my Git work on Windows and for quite a while I have been wanting to move the global .gitconfig file from its default location into my dropbox folder. The reason for this is probably obvious, I do not want to have to make the same configuration changes on multiple machines to get a homogenize Git environment.

So I set out to resolve this but despite numerous stops at my local Google page, I was unable to find any information on how to make Git look for the file in a different location, it always went to look for the file at %USERPROFILE%\.gitconfig.

As a last resort I asked Joshua Flanagan if he had any idea on how I could configure Git or msysgit to make this possible. Unfortunately he had no idea, but he did however suggest that I try using mklink, a command line utility available in Windows Vista and later.

mklink enables you to create either symbolic or hard links for files or directories. What I needed was a symbolic link, which simply explained is like a shortcut to a file but the difference is that the file system will resolve the symbolic link to the real file, where as a windows shortcut is a file with information in it.

To create a symbolic link for your .gitconfig file do the following

  1. Copy your .gitconfig file from the %USERPROFILE% directory, to the directory where you want to store it instead
  2. Delete the .gitconfig file in the %USERPROFILE% directory
  3. Start cmd.exe as Administrator
  4. Enter mklink .gitconfig path\to\your\.gitconfig (notice the actual filename needs to be in the second parameter or you will link to the folder it is stored in)

You should now get a message that a symbolic link was created between the two files. Try making a change in either of them and see that the change is reflected in the other one – this is because you are always editing the same file since the file system resolves the symbolic link into the real file.