Today I was reading about a new tool to use Git on a Mac called GitBox. I generally prefer the command-line, but as it was on sale and mentioned as one of the best clients for Mac, I figured I would at least take a look. When looking through the comments though, one part of a particular review stuck out to me:
DVCS has it’s advantages and disadvantages, but given that the overall model is more complex in nature for individual developers committing code, let’s shelve that and focus solely on the question of whether the git command line itself is overly complicated. (as the review described)
My gut response to this question is ‘it depends’. Perhaps I was a consultant for too long. Git to me seems Unixy. That’s not really a word and doesn’t mean much though. I suppose another way of saying it is: if you’re used to working in unix like environments, it feels comfortable and familiar to you, and if you’re not, it’s never going to feel like anything other than overly complicated. If you’ve written a lot of bash scripts, or regularly tweaked your command line (i.e. bash settings), git feels natural. If you’re not that kind of command-line user, git seems complex.
I would like to strenuously point out that I am in no way trying to offend users who don’t like unix (or unix like operating system) or using the command-line in general. I have some strong personal feelings about it, but at the end of the day, it’s personal preference. If you don’t like using the command-line, then you don’t like it. As an example, when talking through how to us a rest API with someone a month or so ago, I mentioned that they could just toss the URL into curl. I’m so used to reaching for the command-line as my first instinct, that I didn’t even think that for someone not used to the command-line, it might seem complex. It’s just curl -XGET http://someurl afterall.
But it’s never that simple is it? The next question is, ok, how do I post data?
Hmm…..well, something like this:
curl -XPOST http://someurl -H “ContentType:application/json” -d ‘{“jsonstuff”:”value”}’
But reading man pages can sometimes be an acquired skill. For those of us that are used to it, we might quickly notice the quote issue, or quickly find the option we’re looking for with a quick man page search. However, if you just wanted to get something done quickly and you’re not used to these types of tools, it makes a simple test of a rest API turn into an epic undertaking leaving you doing a google search for rest thick clients.
As another example, I recently wiped my mac machine. I hadn’t used it in awhile, as I normally code on an Ubuntu machine. However, the stock git that came with the fresh install of OS X Lion was jarring. There was no colors set, and I didn’t have my customery indicator in bash telling me what branch I was on. I needed to copy some of my bash config over from my other machine.
It’s worth repeating, to effectively use git on the command line, I needed to modify my bash profile. (or bashrc, whatever you want to call it, depending on how you have things setup and distro, etc etc) For a regular command line user, it’s not a problem. But I remember when I first was learning to use linux, and failing miserably to even add things to my PATH the first few times.
So I guess that’s my main point. Git to me fits in well with all my other gnu/unix style command line tools. It feels familiar and as it follows these conventions, I can work with it. But as I have introduced it and other command line tools to fellow programmers, it becomes obvious to me: If you’re not familiar with these conventions and with how to work with this type of command line, it’s going to seem extremely complex.
This app generally is a relieve compared to the terribly complicated git command lineIt’s a common refrain from even a seasoned developer that has been using other tools for awhile, even those familiar with subversion on the command-line. To simplify the discussion, let’s take one part of the obvious usability issues out of the general discussion of git usability: DVCS in general. If using something like Hg or Git after using a more centralized VCS, it’s going to be more complicated by nature. With DVCS you’re effectively managing your own repo and merging with another common repo shared with the rest of your team. With a more centralized system like SVN you’re really just pushing change lists to a repo managed by someone else. I’m sure there’s some power users at every company, but I’m betting a lot of SVN users aren’t doing a lot of branch merging. Even looking at GitBox, which does look like a more simplified view of Git, the overall actions you’re performing are more complicated than say, something like tortoiseSVN.
DVCS has it’s advantages and disadvantages, but given that the overall model is more complex in nature for individual developers committing code, let’s shelve that and focus solely on the question of whether the git command line itself is overly complicated. (as the review described)
My gut response to this question is ‘it depends’. Perhaps I was a consultant for too long. Git to me seems Unixy. That’s not really a word and doesn’t mean much though. I suppose another way of saying it is: if you’re used to working in unix like environments, it feels comfortable and familiar to you, and if you’re not, it’s never going to feel like anything other than overly complicated. If you’ve written a lot of bash scripts, or regularly tweaked your command line (i.e. bash settings), git feels natural. If you’re not that kind of command-line user, git seems complex.
I would like to strenuously point out that I am in no way trying to offend users who don’t like unix (or unix like operating system) or using the command-line in general. I have some strong personal feelings about it, but at the end of the day, it’s personal preference. If you don’t like using the command-line, then you don’t like it. As an example, when talking through how to us a rest API with someone a month or so ago, I mentioned that they could just toss the URL into curl. I’m so used to reaching for the command-line as my first instinct, that I didn’t even think that for someone not used to the command-line, it might seem complex. It’s just curl -XGET http://someurl afterall.
But it’s never that simple is it? The next question is, ok, how do I post data?
Hmm…..well, something like this:
curl -XPOST http://someurl -d “{“jsonstuff”:”value”}”Except, that won’t work. You can’t use double quotes like that. It has to be:
curl -XPOST http://someurl -d ‘{“jsonstuff”:”value”}’That will work. Well, maybe. You might need to set a json content header. If you’re used to using a unix command, you just type man curl, look up the option and do:
curl -XPOST http://someurl -H “ContentType:application/json” -d ‘{“jsonstuff”:”value”}’
But reading man pages can sometimes be an acquired skill. For those of us that are used to it, we might quickly notice the quote issue, or quickly find the option we’re looking for with a quick man page search. However, if you just wanted to get something done quickly and you’re not used to these types of tools, it makes a simple test of a rest API turn into an epic undertaking leaving you doing a google search for rest thick clients.
As another example, I recently wiped my mac machine. I hadn’t used it in awhile, as I normally code on an Ubuntu machine. However, the stock git that came with the fresh install of OS X Lion was jarring. There was no colors set, and I didn’t have my customery indicator in bash telling me what branch I was on. I needed to copy some of my bash config over from my other machine.
It’s worth repeating, to effectively use git on the command line, I needed to modify my bash profile. (or bashrc, whatever you want to call it, depending on how you have things setup and distro, etc etc) For a regular command line user, it’s not a problem. But I remember when I first was learning to use linux, and failing miserably to even add things to my PATH the first few times.
So I guess that’s my main point. Git to me fits in well with all my other gnu/unix style command line tools. It feels familiar and as it follows these conventions, I can work with it. But as I have introduced it and other command line tools to fellow programmers, it becomes obvious to me: If you’re not familiar with these conventions and with how to work with this type of command line, it’s going to seem extremely complex.