> I dropped out of highschool and attended no postsecondary and I don't have any problems with Git.
Git problems arise when people want to do moderately sophisticated things, beyond just committing changes and viewing logs and diffs.
> If git commit and git checkout are too complicated,
If "If git commit and git checkout are too complicated" is your argument, then you aren't doing anything more sophisticated with git than what you learned from a svn to git migration tutorial in five minutes.
People do more with version control than "commit and forget".
If that's all you need, then what you really want is backup software that takes regular snapshots of your filesystem.
I think you may have misunderstood my comment, of course there is more to it then checkout and commit.
Those are the basics, that's where you start. Then you get stuck somehow, and you read more. That's what I did at least.
IMO It's about not giving yourself the impression that the learning curve is insurmountable, you can do it. Starting with the basics and growing up is, I thought, common knowledge for acquiring a new skill.
I find when I get confused and flustered with git, every single time it's because I don't understand [yet] how I got into the current state. I've found that if I take a breath, put the problem aside and focus on figuring out how I got into that broken state, then the solution reveals itself -- not once have I ever lost code as a result of git confusion.
I perfectly understand that there are hordes of programmers for whom messing around with git is far more interesting than the actual code they are working on.
"Man, I just interactively rebased my last six changes so the commits are in a different order, and two of them were squashed into one! Boy, does that feel productive."
> It's about not giving yourself the impression that the learning curve is insurmountable, you can do it
Perhaps I can, but with mercurial around I dont see why I need to. I think no one in their right mind claims git cannot be grokked. They question whether that effort is well spent given there are equally effective alternatives that people find simpler to use.
Other than github I fail to see a compelling reason going for git apart for the linux kernel development workflow of course. Its not a bad tool but not quite the "you possibly cannot and should not do without it" that it is made out to be.
That comment goes out of its way to make things seem complicated. The different synonyms for things are confusing, and are evidence of the fact that Git has evolved over time rather than springing forth fully formed.
That said, the staging area is one of the most useful features of Git, and if you don't want to use it, you can largely ignore it. The staging area allows me to make a few simple changes in the order that they occur to me, but add and commit them (using git add -p) in the order that makes the most sense for code review.
Also: I highly recommend setting up shell aliases for the most commonly used commands, whether you use Git or anything else. "gco" is much faster to type than "git checkout", etc.
> The staging area allows me to make a few simple changes in the order that they occur to me, but add and commit them (using git add -p) in the order that makes the most sense for code review.
Ah, but note that "git commit" also takes a "--patch" argument. So the add-and-commit case you are describing can in fact be done in one step. That step uses the index, but only for its implementation; you're not aware of it. "git commit --patch ..." appears to move selected changes from the working copy straight to a new commit on HEAD. The command could be implemented in a version of git that doesn't have an index.
Those little commits you make in preparation for review are your true staging area.
Git problems arise when people want to do moderately sophisticated things, beyond just committing changes and viewing logs and diffs.
> If git commit and git checkout are too complicated,
If "If git commit and git checkout are too complicated" is your argument, then you aren't doing anything more sophisticated with git than what you learned from a svn to git migration tutorial in five minutes.
People do more with version control than "commit and forget".
If that's all you need, then what you really want is backup software that takes regular snapshots of your filesystem.