Feeling like a Git

(home)

I keep hearing about how cool Git is, and how much better it is than Subversion, so much more powerful and flexible. I must admit that every time I look at Git I tend to notice something new interesting that I feel I could use in my day-to-day development life. Sadly, every time I try to go a little bit further I’m left with this feeling that Git is very… “Linux” (for want of a better description).

It feels like there are 400 commands, each of which is basically the same, yet possessing subtle differences; only 4 of which I’m ever going to use. It seems, as an inexperienced Git user, like I’m drowning in a pool of commands that all look the same and give me no indication as to which are more important or more common than the others.

To put it another way, I keep hearing about the “power” but it seems like nobody is paying attention to the “usability”.

I’m sure I’ll get rubbished for that by people who want to tell me it’s much more usable than Subversion because you can do x, y and z (or you can do them easier than you can in Subversion). While that might be true, I don’t define usability as a list of things you can do, but rather how easy it is to figure out what I need to do without having to dive into mountains of man pages or countless tutorials.

For example, consider the typical command used to commit something with Git:

git commit -a

-a? what’s the -a?

A quick look at the man page tells me:

Tell the command to automatically stage files that have been modified and deleted, but new files you have not told git about are not affected.

Great. Everybody get that? No? I didn’t think so. What the hell is the stage and what has it got to do with my commit? I just want to commit my stuff dammit!

If you trawl any number of the Git tutorials Google finds, they’ll either ignore the -a like it’s not even there, or offer some cursory explanation that amounts to “everyone does it that way”. I’m left to wonder, if everyone does it that way, why isn’t that the default?! Sure, I could ignore it, but like a lot of developers I’m an anal-retentive. Leaving it there, not knowing why, just gnaws at me, like that little switch is laughing at me knowing I can’t get rid of him despite not wanting him there. Or maybe I can get rid of him…? who the hell knows. I just want to commit my stuff and move on with life.

Let me give you another example. Consider the situation where I want to revert back to the way the repository was before I started making my most recent changes. Perhaps I deleted a file and now I want it back.

Git documentation and tutorials start throwing all these things at me. There’s git-revert, git-reset, git-reset --soft and git-reset --hard. Even worse, there are all these warnings about being careful when using some of them.

I type “git revert” and it wants more command line arguments. Further, the options it throws at me talk about editing commit messages or not doing a commit. Of course I don’t want to do a commit, I want to get back to a known-good state! I give up on revert and try “git reset”, it tells me that the file I accidently deleted was locally modified, giving me a hint of hope that Git has seen this and reverted my state. A quick check reveals… NOTHING! git-status confirms that the file is still deleted. What happened? I don’t know. I try “git reset –soft” and get no output. I check the status again and again I see that nothing has happened. I finally give up and try for what feels like the a-bomb option, “git reset –hard”. Huzzah! It worked! Why? No ******* idea, but it worked. What is the point of revert, reset or reset –soft? I still have no idea. I’m sure there is a point, but I just wanted to get a file back.

Just telling me that I have to use -a or –hard isn’t a solution. If I HAVE to use a particular switch to complete some common, simple task, I should be able to understand why without having to learn a whole bunch about the way Git works internally.

I think this is what Subversion really gets right. There are a small bunch of core commands that are well defined, well named and “do what they say”. Yes, for some tasks SVN is cumbersome or might not even do what you want, but it gets the fundamental usability ideas right.

Don’t get me wrong, as with Linux, once you climb the learning curve everything might be fine. Before I used a Mac I ran Gentoo. Although I hated it at first, I grew to love it (faults and all) over time, but the learning curve required Crampons, and in reality, the hostility of it is going to turn a lot of people off.

This whole class of problem, this lack of intuitiveness, is why I describe the experience as very “Linux”. It’s all there, it’s all functional, it can do amazing things when utilized properly, but the whole thing can is so terribly unintuitive that I just end up annoyed and going back to a tool that 95% of the time, gets out of my way.

Tags: ,

2 Responses to “Feeling like a Git”

  1. Russell Keith-Magee Says:

    I can fully relate to your experience with Git - all I can advise you is persevere, because it is worth it in the end. If only because of the git-svn and git-stash commands, Git is a big bucket of WIN for me.

    There are some very big conceptual differences between Git and SVN. The way Git does things - especially the -a, –soft and –hard style options - are very different to the way SVN does them, and they make sense once you grok the reasons, but I haven’t come across anyone that has done a good job of explaining those reasons. One day I may have to try my hand at writing a Git tutorial (hell, you could probably turn it into a book), because for me, the documentation of git is probably the single biggest impediment to adoption. Grab me online one evening and I’ll can try giving you the crash course.

    Oh - and as for SVN “gets the fundamental usability ideas right” - I challenge to you defend svn branching and merging behaviour once you have done a seen a Git merge in action.

  2. tim Says:

    I will have to get some help at some point I’m sure, and I’ll be knocking down your door when I get stuck :)

    With regard to my comment, it was more means on usability in terms of simple defaults with commands being straightforward and doing what they say. I notice that not only are there so many arguments you can pass to Git commands, but that situations that use one or more arguments tend to be much more common than with SVN. Perhaps this is just a reflection on the different approaches, but I think it does substantially contribute to the “linux” feeling of the whole thing: functional, if a bit hostile.