Is this serious?<p>Can't commit like you expect?<p><pre><code> git commit -a
</code></pre>
Alternatively stage a commit<p><pre><code> git add filename
#then commit it
git commit -m "commit message"
</code></pre>
worst <i>Git’s just version control.</i>
As I recall version control is pretty important to the software developer toolbox. I know its pretty important to mine.<p>If it takes you that long to get up and running with Git, I can't imagine what kind of developer you are.<p>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.
<i>Version control is hard, let's go shopping!</i><p>Kidding aside, arguments like this just do not hold water. If the tool doesn't fit your needs profile, 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.<p>The guy who dedicates three posts to loop invariants and formal (ish) reasoning practices thinks git is hard?<p>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!
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.<p>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.<p>That said, the OP should try Mercurial if he wants something with a slightly shallower learning curve.
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.<p>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.<p>It is perfect for little "6 file projects". Try getting started so quickly like this in CVS or subversion:<p><pre><code> git init
git add .
git commit -a -m "My own repo"
</code></pre>
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.
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.<p>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 <a href="http://progit.org/book/ch2-0.html" rel="nofollow">http://progit.org/book/ch2-0.html</a> otherwise it just seems like a rant by someone who just doesn't want to try and learn something new (over CVS).
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).<p>I <i>have</i> 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.<p>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?<p>Yowza.
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.<p>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.<p>Instead, all it provides is one, single, minor example of a potential issue: you can't commit the same way as CVS or subversion.<p>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.
I found the fossil dvcs referenced in a comment interesting.
<a href="http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki" rel="nofollow">http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki</a>
Unlearning CVS/svn is the truly difficult part of learning git.<p>These complaints could only come from someone who has used CVS/svn in the past and expects git to work exactly the same way.<p>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?