Git is a Harrier Jump Jet. And not in a good way | Hacker News Reader

Git is a Harrier Jump Jet. And not in a good way

reprog.wordpress.com

18 pointsMikeTaylor33 comments

Is this serious?

Can't commit like you expect?

    git commit -a

Alternatively stage a commit

    git add filename 
    #then commit it
    git commit -m "commit message"

worst Git’s just version control. As I recall version control is pretty important to the software developer toolbox. I know its pretty important to mine.

If it takes you that long to get up and running with Git, I can't imagine what kind of developer you are.

Edit: I should add an addendum to this: I don't mean this as a personal attack, I'm just kind of incredulous about all this talk about version control is hard. I have used cvs, svn, mercurial and git and I never found them particular hard to get up and running with them. All source control has its pain points, but usually getting started on a project that has already been using it, or a new project isn't one of these points.

Yeah, seems he isn't around people who know git. E.g.:

  Me: Why?  I already added them before, why do I need to add them again?

  They: You just do, OK?

The answer isn't "You just do," neither is it complicated. You need to re-add files after you've further modified them, because you aren't adding files, you're adding changes to files at the time you added it.

After all, why should your VCS assume that your file layout consistently and meaningfully aligns with your changes? I've found it's much more meaningful to cut up a body of work into several commits after the fact using a tool like GitX.

Version control is hard, let's go shopping!

Kidding aside, arguments like this just do not hold water. If the tool doesn't fit your needs profile, use something else.

I agree. Also, I use git for small projects due to it's ease to set up. Subversion takes far too much work to just start using. I sit down, create a folder, code in it, and git init and I have all of my code in version control. I agree it doesn't degrade easily, but like the above comment states, if it doesn't work, either fix it or use something else.

Wow. Generally, I've really loved the Reinvigorated Programmer. This feels like it was written by someone else, or is some kind of joke.

The guy who dedicates three posts to loop invariants and formal (ish) reasoning practices thinks git is hard?

I feel like this post is from some kind of bizarro-world. Even more so since I'm reading on my phone, so there are no sushi pictures!

There's only one sushi-picture in there, and two cheesy ones of other things. The One ring and an aircraft.

Using Git--for simple things--is not that hard. Seriously, it would take 10 minutes to write shell scripts that simulate Subversion's behavior if one wanted to. It would take far less time than writing a blog post about it, even with only a cursory knowledge of Git.

Further, the tendency of some developers to bitch about using any tool outside their comfort area is annoying. Guess what, users of open source software: unless you're programming using assembly, you use the tools you do because people decided to try something a little bleeding-edge, adventurous, and new. The idea that developers should always "stick with what works" and resist change (even if they don't always like it) is kind of freeloading. Some day, the tools one is using now will be obsolete for the purpose it's being used for now. Be ready to accept change.

That said, the OP should try Mercurial if he wants something with a slightly shallower learning curve.

Version control software, like, say, file systems, is not an area where most people should be "adventurous". They should just work, and mostly keep the hell out of your way.

And Git just works. At least on the same level as not expecting "rm -rf /" to "read mail really fast".

It works, yes, but there is truth in what that guy says. It's fiddly, and often not obvious.

I think you can sum up that article as "Git is terrible because I couldn't figure it out."

If you're only using 3% of git's facilities, then you're doing it wrong. You're probably doing it wrong because you don't understand the other 97%. That's OK, but don't pretend that the stuff you don't understand is useless.

Almost every time I learn something new about git, it is something that is immediately useful.

Git is a harrier jump jet when you need it, and a motorcycle the rest of the time.

It is perfect for little "6 file projects". Try getting started so quickly like this in CVS or subversion:

  git init
  git add . 
  git commit -a -m "My own repo"

Bam, done. Now you can just do git commit -a whenever you need to add something new. Sure, the index might feel strange to some people, just skip it with -a.

And for reduced typing, you can even alias it in your .gitconfig:

    [alias]
      cam = commit -a -m

Then you can just type 'git cam "look what I changed!"'

Anecdotally, everyone I know who's been taught git with no prior VCS experience has had no problem with learning it.

Git has certain usability issues, although this article didn't seem to cover them. For example, previewing changes about to be pulled from a remote repository, or resolving conflicts after a bad pull, are complex and counter-intuitive operations.

But internally Git is incredibly simple and well designed. It just needs some polish to make all common use cases intuitive for the casual user. The UI should always guide the user how to proceed in unclear situations. Common use cases should have simple shortcuts, instead of requiring 2 or 3 separate commands.

As someone who doesn't understand version control extremely well I can say I don't have much of a clue when it comes to CVS and all the configuring to make it behave normally but git is extremely easy for someone who only needs a little version control. If you don't get it read this http://progit.org/book/ch2-0.html otherwise it just seems like a rant by someone who just doesn't want to try and learn something new (over CVS).

Yes. The times I used CVS or subversion were more frustrating than learning git. Especially with all the server setting up you (used to?) had to do. And all the warnings about never using the filesystem-native renaming tools.

Git can get complicated later on, when you are doing complicated things. But on easy things, git is easy enough.

(And so are darcs and mercurial and the other modern version control systems.)

Wow. I'm surprised at the one-sided-ness of comments here at HN. I read the article and totally agreed. I've been trying to deal with all the complexity of working copy/index/local repostory/remote repository/other remote repositories, merging changes back and forth, and umpteen other things, for a good few months now. It's genuinely Hard (TM).

I have definitely done occasionally awesome things, like amending commits with small noticed typos before pushing, stashing is totally awesome, cheap branches are mostly convenient. But there's _so many_ layers, and nothing (that I've yet discovered) that lays it out in a manner that makes it easy to understand.

I've a lot of past experience with Subversion. I used SVK for a while, so I could get local dev branches and commits without pushing to the central repository. But git continually confuses me. Plenty of it is un-learning other VCSs (no, to get rid of that mistaken change, I don't revert the file, I checkout the file. revert is a command but it does wholly other things.) Not to mention the many names for things. Local, staged, cached, indexed?

Yowza.

Personally, I think that git is hard to learn if you try to think of it in terms of your previous VCS. As you say, you have a lot of svn experience, so maybe that's the issue.

Really, at its core, git is incredibly simple. That's one of the reasons that it's hard. It's just a DAG of changesets, and every command lets you manipulate that graph, or give points on the graph names.

Anyway, I'd echo several people's sentiments here: http://progit.org is a really good explanation, and also fairly short.

I'm a recent convert to Git. Yes, it's confusing to newcomers. So is Subversion and all the rest. I just don't think there is any version control tool where the commands are totally intuitive, and there probably never will be.

The good news is that as more people flock to Git, they'll create better tools. Look at some of the wonderful things people have created for Subversion; for instance, the beautiful Mac client Versions, which is aimed at web designers rather than programmers. There's no reason something similar can't be built for Git. The average user shouldn't have to use the command line. Once those tools are in place, it won't matter how unintuitive Git's terminology is.

I don't use git but am considering it. So I was hoping this article might point out a few things I should beware of before getting started.

Instead, all it provides is one, single, minor example of a potential issue: you can't commit the same way as CVS or subversion.

Not sure why it took the author so many words to get around to saying that. And if there are other problems with git, I'm not sure why the author doesn't mention them.

It's kind of laughable, because you just need to add a flag - "git commit -a" to do what he wants.

Right. The entire article is about how you need to do "git add" before committing.

I can tell you read it reaaally carefully.

Umm, my point is that you don't.

I found the fossil dvcs referenced in a comment interesting. http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki

Buried in a bit of a rant is a very good point about using the right tool for the job, though I'm doubtful this was the actual intention of the post.

Git is a Harrier jet all right. I just got into it and keep thinking to myself, "This thing can turn on a dime, Macross Zero-style!"

I was just thinking that maybe it's a Harrier since you can easily tilt the thrust the wrong way and end up screwed. But you can always get back to where you were, so perhaps it's a Harrier with a time machine.

At least unless you are doing something like --force or --hard. But you should be smelling that those commands do something potentially non-recoverable.

Unlearning CVS/svn is the truly difficult part of learning git.

These complaints could only come from someone who has used CVS/svn in the past and expects git to work exactly the same way.

Are there any extant articles of someone who has never used source control at all before having these problems with git specifically and not other SCMs?

http://book.git-scm.com/

http://progit.org/book/

Was there any genuine content in there?

Reply on news.ycombinator.com