I’ve blogged about improving the performance of Git on Windows in the past and rightly labelled the suggested solution as a bad hack because it requires you to manually replace binaries that are part of the installation. For people who tend to use DVCSs from the command line, manually replacing binaries is unlikely to be a big deal but it’s clunky and should really be a wakeup call for some people to include a newer base system.

The Windows build of Emacs 24.5 doesn’t ship with SSL and TLS support out of the box. Normally that’s not that much of a problem until you are trying to access marmalade-repo or have org2blog talk to your own blog via SSL/TLS.

In a previous blog post I explained how you can substantially improve the performance of git on Windows updating the underlying SSH implementation. This performance improvement is very worthwhile in a standard Unix-style git setup where access to the git repository is done using ssh as the transport layer. For a regular development workstation, this update works fine as long as you keep remembering that you need to check and possibly update the ssh binaries after every git update.

OK, I admit it - I’m a dinosaur. I still use the command line a lot as I’m subscribing to the belief that I can often type faster than I can move my hand off the keyboard to the mouse, click, and move my hand back. Plus, I grew up in an era when the command line was what you got when you turned on the computer, and Windows 2.0 or GEM was a big improvement.

It’s one of those days, thanks to a hard disk going south I ended up having to rebuild the system drive on one of my machines. After putting the important software back on there - “Outlook and Emacs”, as one of my colleagues calls it - I had to reapply some of the usual tweaks that make a generic developer workstation my developer workstation.