My guess is Hg, as it's simpler. 90% of my SVN work is done with update, checkout, and commit. Really, why so many more commands for essentially the same work cycle?
Ok, that question wasn't rhetorical, I'm curious.
My guess is Hg, as it's simpler. 90% of my SVN work is done with update, checkout, and commit. Really, why so many more commands for essentially the same work cycle?
I prefer hg for just this reason. But unfortunately, it looks like git is going to win. Why? http://github.com. Fortunately, they're both pretty good, and so living with git isn't the end of the world.
1) The person who wrote it is famous. It wouldn't have been taken seriously had (almost) anyone else written something comparable.
2) Network effects apply strongly here. You can't just use something else if you want to collaborate with people who use it.
I'm not very happy about having to use git, but the pain numbs after a while. And, to be fair, it does have some cool features, although little-to-nothing inherent to git or its implementation.
1. I can commit things locally before committing them to the main repository. This allows me to commit something in a manner that separates it from all future changes, but test it for a few more days in future development before I actually push it to the main repository.
2. I can correct past commits. This means I don't have to clutter up the history with "fix typo"; I can just amend the previous commit. Obviously this isn't useful for stuff far back, but if I commit something and 2 minutes later someone points out a typo, I can fix it. A messy history makes development and bugfinding harder; git helps avoid it.
3. Git diff is formatted a bit more nicely than svn diff, IMO.
Your comment is a little like saying "man, a visual text editor sure beats using ex on a teletype!" in the middle of a vi/emacs war.
"Really, why so many more commands for essentially the same work cycle?"
Add git rebase -i into the mix, and I can wrap up all my externally-uncommitted changes into one perfect changeset.