![[lang]](/images/eye.png)
ways in which git makes the opposite of sense to me |
2009-02-06
|
DISCLAIMER: I originally wrote this post 18 months ago but never posted it because it was unusually negative.
Recently, with GStreamer switching to git, and GNOME thinking of moving to it as well, I thought I'd pick the post back up and see if git had improved since writing it. For me, the most frustrating things about git are:
- the user interface experience is the absolute worst of all of them since tla was around
- there is no obvious way to do it - clearly shown by the 50 different git tutorials, and the myriads of git commands that are very similar-sounding and have strange descriptions that to the layman sound like they would do the same thing
Personally, I remain convinced that it would be easy to start a git hater's blog (much like the linux hater's one) and fill it with content, though I doubt that will stop me from using it in practice.
Feel free to rush to the defense of git, insult me, call me stupid, whatever you want! I just thought it'd be an interesting exercise to see if my frustrated vitriol from last time still held up.
I'll annotate each part with today's experience in italics, and finish off with a final git score.
Exhibit A:
[thomas@ana git]$ git init Initialized empty Git repository in .git/ [thomas@ana git]$ mkdir t [thomas@ana git]$ git add t The following paths are ignored by one of your .gitignore files: t (directory) Use -f if you really want to add them. [thomas@ana git]$ find . -name ".gitignore"
There is no .gitignore file, so what are you talking about ?
2009: this now actually works without problems. Score one for git! 1 out of 1 for git usability improvements.
Exhibit B:
[thomas@ana tmp]$ git clone gt clone Initialized empty Git repository in /home/thomas/tmp/clone/.git/ fatal: 'gt': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly fetch-pack from 'gt' failed.
Ok, so I have a typo. But this is how you choose to let me know ?
"unable to chdir" OR "not a git archive". Hey, YOU're the computer. And git, you're the program tracking these things, you can't tell the difference between a git archive and something that is not ? Why don't YOU tell me which of the two it is instead of failing to handle errors in a logical way.
Also, I have no idea how it knew that I was on the phone with my mom and my mom got angry at something I said and ended the conversation. Oh ,wait, that wasn't what you were referring to when talking about unexpected hangups ?
And I thought fatal meant fatal. Apparently the first fatal was not fatal enough to already stop, you prefer confusing me with another fatal. Which one of the two should I be fixing ?
Kudos though for cleaning up the failed creation of the clone repository.
Please, when I make this simple mistake, tell me only: "The repository 'gt' does not exist."
2009: behaviour exactly the same. 1 out of 2 for git usability improvements.
Exhibit C:
[thomas@ana clone]$ ls /usr/bin/git-* | wc 139 139 3158
Compared with
[thomas@ana clone]$ ls /usr/bin/e* | wc 69 69 1244
I would say that the Lobby For Commands In /usr/bin Starting With G has gone a little overboard here.
2009: only 131 commands left for git. In the interest of preserving my sanity I'm not even going to try figure out which ones got removed or replaced or folded. 1 out of 3 for git usability improvements.
Exhibit D
Maybe that last one was an unfair stab ? Maybe 139 binaries come for free anyway so I should not complain ? I wasn't sure either first. Until I took two random entries from there and ran:
[thomas@ana clone]$ git whatchanged -h fatal: unrecognized argument: -h [thomas@ana clone]$ git citool -h usage: /usr/bin/git-citool [thomas@ana clone]$
Care to guess how many of these binaries have no useful -h output ? I sure don't want to find out, there's 139 binaries to check. 130 of them have manpages though - I guess that could be one reason why git implements "git command" by having a binary "git-command" - how else are you going to document this monster ?
What I *really* wanted to do when finding this out is to find a command that would show me which files are not under version control and give that to me in the most easy to parse way. git status is something, but maybe one of those 138 other commands gives me something better ?
(answer after some random command 'bisecting': git ls-files --others)
2009: behaviour has changed, but is still unhelpful
[thomas@ana git]$ git whatchanged -h fatal: bad default revision 'HEAD' [thomas@ana git]$ git citool -h
The last one now pops up a TK dialog box that says "couldn't open /usr/share/git-gui/lib/tclIndex": no such file or directory. 1 out of 4 for git usability improvements.
Exhibit E:
In my quest to figure out what some git commands do without wading through the man pages, I've resigned myself to the black box approach.
[thomas@ana clone]$ git describe fatal: cannot describe '02d3a05f1e9710f9a6683ed8a62c9bd2ff3680a8'
For once I must side with git on this one. I have no way to describe that hex string either.
2009: output changed, but equally unhelpful:
fatal: Not a valid object name HEAD
Still inclined to side with git, I don't name my objects HEAD either. 1 out of 5 for git usability improvements.
Exhibit F:
I'm following this simple tutorial and it suggests that git has a slightly different model for committing. Most VCS systems have you "add" paths to tell the VCS you want to track them. Git seems to have something in addition - it has "files that it tracks", "files that it tracks and is going to commit in the next changeset", and "files that it doesn't track". git add then seems to be used to add to "the next changeset", and as a result also add it to "files that it tracks". A little confusing, but OK. So basically, to do a commit, you must add files to the commit.
The tutorial explains that you can do both at once by using git commit -a. Obviously the two step process of committing was so unintuitive that they made an option do to both, and the tutorial thinks this shortcut is important enough to mention.
Except that this happens:
[thomas@ana git]$ touch 1 [thomas@ana git]$ git commit 1 error: pathspec '1' did not match any file(s) known to git. Did you forget to 'git add'? [thomas@ana git]$ git add 1 [thomas@ana git]$ git commit 1 Created commit 79e67c26b27c80f7f0ddc37293cbc022f932c968 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 1 [thomas@ana git]$ touch 2 [thomas@ana git]$ git commit -a 2 Paths with -a does not make sense. [thomas@ana git]$
I guess I should be lucky it didn't call me stupid outright. It may not make sense to you, git, but I guess this is how my intuition works when I read your tutorial and you've already made it clear to me that you're not planning to have your help or usage output to be helpful or useful or for that matter even be period.
As a hint, here's what I expect to happen when I run git commit -a 2:
- git adds the file 2 to the next commit
- git commits the change to file 2
That wasn't so hard to make sense of now, was it ?
2009: slightly different behaviour. First off, the actually helpful suggestion from before (did you forget to add 1) is now gone. Why ? The second part is still the same, exactly as is. 1 out of 6 for git usability improvements (and actually a step back).
Exhibit G:
[thomas@otto git]$ ls /home/thomas/tmp/git/repo/.git/ branches/ description hooks/ objects/ config HEAD info/ refs/ [thomas@otto git]$ git checkout /home/thomas/tmp/git/repo fatal: Not a git repository
What do you mean, not a git repository ? I gave you one argument that clearly is a repository. Could you try and tell me what is wrong in a way that us humans can read ?
2009: different error:
[thomas@ana git]$ git checkout /home/thomas/tmp/git error: pathspec '' did not match any file(s) known to git.
I'm guessing I should be giving it an additional argument. Hey, wouldn't that be a nice understandable error message instead ? 1 out of 7 for git usability improvements.
Exhibit H:
gitk is in Tk. Tk !!! 1991 called and they ... Oh never mind, not even going there. No, really. Start it up and click on 'File'. Then move the mouse pointer to 'Edit'. Is it just me, expecting the logical thing to happen, while nothing happens at all ? At a guess, this behaviour was probably for those people who were logging in to a remote X server over a 300 baud modem.
2009: still the same. To be fair, the application is actually pretty useful, you'd almost forgive it being written in tk. Still, 1 out of 8 for git usability improvements.
If you're still here, feel free to point out where git's behaviour really was my fault. I'm all for learning more about why things are the way they are. I'm just not convinced at all yet that git has made huge inroads on the usability level as its defenders often claim when discussing git vs. bzr.