A few weeks ago I read the blog post Git and command-line fear by James Gregory. He argues against the common Git on Windows complaint of poor Windows support. While I appreciate James’ position that this is not entirely true, and that most people do associate Windows support with GUI based tools or Visual Studio integration, I do disagree with his assertion that command line tooling is a valid use case.
My time in development starts in the stone age when there were only command line tools, and I have followed the evolution of the development environment through to the current integrated development environments. I spent nearly twenty year in the command line, and only around ten was in the GUI world, and even then not fully GUI. Yes, I admit – I do drop to the command line every now and then. In all of these cases, it is because the tooling is not up to the job – in my opinion. I work in the Windows environment. I develop Windows client and server side applications, and every time I drop to the shell, I consider it a failure.
I am not opposed to the command line being used by other people, but I consider the benefits of graphically describing what I want to be a significant benefit over needing to remember cryptic command line parameters. I remember the pain of configuring my build environment using make files, environment variables, and ensuring my paths are correct. To me, this is akin to fixing the order of linkage in old C programs. I hated it then, and I still do. It is an inefficient waste of my time.
In the case of Git, the tooling is not great on Windows. Yes, there are command line tools, however, the setups are not always correct. I used the recommended setup for GitHub using the GitHub Guide for Windows for Noobies, and while it worked from the command line the first time, it failed subsequent times. Further, the Git gui tool it installed failed every time. The folks at GitHub were fantastic and helped me right away. I needed to change which SSH tool I was using, 
{: .float_right }and after that everything worked. Tools should just work. When I buy a hammer, if I needed to change the head because the one that came with it didn’t work when it was cold, then I am using the wrong tool for my environment. That is the key here. My environment is Windows. The command line is a hold over from the prehistoric age of computers, much like the tail bones in humans. Tools not designed to work well within the Windows world, and not properly tooled for the environment.
Having said all that, I also do not believe that Git is all that poorly supported on Windows. The Git extensions that provide Windows Shell extensions and a Visual Studio plug-in are quite good. They are almost on par with TortoiseSVN. They only need some more maturity. Having installed them, I have not had to go back to using the Git command line again. Happily, I couldn’t even remember the commands or their parameters. Most likely these command line programs and their options are just being called by the shell extension, but I don’t care. Visual Studio is probably still calling the command line C/C++ compiler and linker, and I also don’t care. The point is that the tools have conformed to the environment in which they are used.
Now, James does make a good point when he says:
If you don’t like what Git does, then that’s fine, but don’t label yourself as Alt.Net or a continuous improver if this sounds like you: “I define myself by choosing the best tool for each situation, but there’s no way you’ll get me using the command-line.“””
However, I argue that it is a fair statement to say that I won’t use a command line because that is not my working environment, thus a tool that only works that way is not acceptable. I would not use a horse to go to work, though that is still a valid means of transportation, and in the right environment would be better than the bus, train or car. However, in the urban environment in which I live, a horse is not an acceptable option – not because it is a better or worse tool, but because it is not designed for my environment.
The bottom line is tooling must comply to my environment, whether I am open-minded or not. My development environment is a critical aspect of my development efficiency, and deviations from that environment are not acceptable to me. James mentions the benefits of R# (full disclosure, I use CodeRush and Refactor), and I agree with him. However, the benefits of R# would be nearly worthless when used from a command line. It’s primary benefit is the way it integrates into your work environment and seamlessly allows you to perform high order operations on your source code than the default editor provides. This is precisely my point. A well integrated set of tools is greater than the sum of its parts.
James mentions one other situation for which the command line is appropriate, command line development environments like Rails. I agree. In that particular case the tooling for Rails on Windows is still immature, much like the early days of .NET when the command line was all that was available. In that case, the command line is the defacto standard environment, and using more command line tools in that case fits. To me, that is a case in which the Rails development model is platform agnostic, and either GUI tooling doesn’t fit or the development model hasn’t evolved far enough to support GUI tooling. I don’t enough about Rails to say which one it is, but my experience with development tooling over the years has convinced me that development environments usually move from a set of command line tools towards an integrated visual development environment. Most of the time this move makes the environment more efficient, but I am sure there are exceptions. Many of the Java developers I know prefer working in Eclipse than in command line or in some of the ‘richer’ GUI environments. However, the few I asked say they always configure their environment to call any of the command line tools they frequently use.
I will choose the best tool for each job, but part of my determination of ‘best’ is the development environment. What do you think?