6 ms·

Summary: neither is ready yet. Wait for one to get good enough to make the other unnecessary. My guess is Hg, as it's simpler. 90% of my SVN work is done wit

Summary: neither is ready yet. Wait for one to get good enough to make the other unnecessary. 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.

DarkShikari 18y ago
I use git, so I'll explain a few things I like about it. 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.
- holygoat 18y ago
  I hate to point out the painfully obvious, but the discussion in this article isn't about why one should use a DVCS, but about the respective pros and cons of Git and Mercurial. 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.
  - DarkShikari 18y ago
    But I'm not responding to the article; I am responding to the parent post, who asked the following question: "Really, why so many more commands for essentially the same work cycle?"
jon_dahl 18y ago
I'd say they're both ready, and I've used them both for over a year now with no problems. 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 http://github.com. Fortunately, they're both pretty good, and so living with git isn't the end of the world.
- maw 18y ago
  I agree that it looks like git is going to win, but for entirely different reasons: 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.
icky 18y ago
I prefer git because my work uses SVN, and nobody needs to know I'm using git-svn. Add git rebase -i into the mix, and I can wrap up all my externally-uncommitted changes into one perfect changeset.

DarkShikari 18y ago

I use git, so I'll explain a few things I like about it. 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.

holygoat 18y ago
I hate to point out the painfully obvious, but the discussion in this article isn't about why one should use a DVCS, but about the respective pros and cons of Git and Mercurial. 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.
- DarkShikari 18y ago
  But I'm not responding to the article; I am responding to the parent post, who asked the following question: "Really, why so many more commands for essentially the same work cycle?"

jon_dahl 18y ago

I'd say they're both ready, and I've used them both for over a year now with no problems. 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 http://github.com. Fortunately, they're both pretty good, and so living with git isn't the end of the world.

maw 18y ago
I agree that it looks like git is going to win, but for entirely different reasons: 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.

icky 18y ago

I prefer git because my work uses SVN, and nobody needs to know I'm using git-svn. Add git rebase -i into the mix, and I can wrap up all my externally-uncommitted changes into one perfect changeset.