5 ms·

There are two kinds of articles about DVCSs: (1) git, hg, bzr are all better than whatever you're using now; (2) git is completely revolutionary, a whole new pa

There are two kinds of articles about DVCSs: (1) git, hg, bzr are all better than whatever you're using now; (2) git is completely revolutionary, a whole new paradigm. This is, of course, the latter sort. I'm wondering why hg, etc. are never called "a whole new paradigm". I've used all three. Clearly, hg & bzr are extremely similar, while git works a little differently (the staging area, the differing semantics of "add", etc.). But I don't see that git has significantly more awesomeness than the other two. Am I missing something?

jimmyjazz14 16y ago
It's kinda sad that people have kinda forgotten about darcs (at least in the mainstream) which is still an interesting project despite some of its shortcomings (and one of the first good DVCSs). That said I still prefer git.
jmillikin 16y ago
The second type of article is usually written by converts from legacy VC systems (cvs/svn) who have never experienced a DVCS before. They attribute the obvious improvement in usability to Git, never venturing to try anything else; possibly due to the same fundamental lack of curiosity or self-improvement that leads to using CVS/SVN at all (post 2005). What's more, the migration from a single-branch to multiple-branch model is so empowering that such users tend to view all of Git through rose-tinted glasses forever after. Compared to that experience, relatively minor usability improvements like Bazaar's "every working copy has its own tree" or Mercurial's queues seem insignificant and/or unimportant.
- nupark 16y ago
  ... possibly due to the same fundamental lack of curiosity or self-improvement that leads to using CVS/SVN at all (post 2005). I (and my successful small business) still use SVN, and have done so since 2007. This choice has nothing to do with "fundamental lack of curiosity or self-improvement." It's a choice born of careful reasoning regarding the suitability of using DVCS in a centralized organization.
- dexen 16y ago
  I've been toying around with Hg for some time before Git. Indeed, DVCS by itself implies high degree of flexibility and whatnot. However, I'd still like to single Git out, because of its storage format. In Hg, for every file in your repo, you get one storage file holding revisions -- plus one master file with changelogs. It's just boring files all the way down. In Git, every object (file, tree of files, commit with a tree of files & parent commit(s)) are represented by hash. The data itself is stored somewhere -- in an interchangeable format (currently two formats are used: blob and pack with index). Storage is somewhat decoupled from toolkit. You can even fix a broken repo by literally copying in file(s) with proper content. But the true power comes from somewhere else: you can envision defining own data types, beyond files, trees and commits, and plugging them into Git. And having them play along with the usual ones. A general content-addressable storage :D (Too bad Venti [1] was invented a bit earlier) I believe Fossil (the DVCS [2], not the FS [3]) comes pretty close to that, too. -- [1] http://en.wikipedia.org/wiki/Venti http://en.wikipedia.org/wiki/Venti [2] (the DVCS) http://en.wikipedia.org/wiki/Fossil_(software) http://en.wikipedia.org/wiki/Fossil_(software) [3] (the FS) http://en.wikipedia.org/wiki/Fossil_(file_system) http://en.wikipedia.org/wiki/Fossil_(file_system)
zb 16y ago
He doesn't seem to be claiming that Git is more revolutionary than Mercurial/Bazaar/&c. as a VCS. I think it's fair to say that Git makes it easier to build some system other than a VCS from it, since all of the low-level commands for directly manipulating the repository are exposed in the shell. Contrast that with Mercurial, which doesn't even have a Python API. (For the record, I have actually built such a system on top of hg, and I'm pretty familiar with git.)
j_baker 16y ago
I think it boils down to difficult to quantify factors: most notably, love. In spite of all of git's warts (or perhaps even because of them), it's very clear that git is a tool that was created by the people who would be stuck using it. I'm not saying that isn't true about the other ones. I'm just saying it just doesn't shine through as much.
deleted 16y ago
[deleted]

jimmyjazz14 16y ago

It's kinda sad that people have kinda forgotten about darcs (at least in the mainstream) which is still an interesting project despite some of its shortcomings (and one of the first good DVCSs). That said I still prefer git.

jmillikin 16y ago

The second type of article is usually written by converts from legacy VC systems (cvs/svn) who have never experienced a DVCS before. They attribute the obvious improvement in usability to Git, never venturing to try anything else; possibly due to the same fundamental lack of curiosity or self-improvement that leads to using CVS/SVN at all (post 2005). What's more, the migration from a single-branch to multiple-branch model is so empowering that such users tend to view all of Git through rose-tinted glasses forever after. Compared to that experience, relatively minor usability improvements like Bazaar's "every working copy has its own tree" or Mercurial's queues seem insignificant and/or unimportant.

nupark 16y ago
... possibly due to the same fundamental lack of curiosity or self-improvement that leads to using CVS/SVN at all (post 2005). I (and my successful small business) still use SVN, and have done so since 2007. This choice has nothing to do with "fundamental lack of curiosity or self-improvement." It's a choice born of careful reasoning regarding the suitability of using DVCS in a centralized organization.
dexen 16y ago
I've been toying around with Hg for some time before Git. Indeed, DVCS by itself implies high degree of flexibility and whatnot. However, I'd still like to single Git out, because of its storage format. In Hg, for every file in your repo, you get one storage file holding revisions -- plus one master file with changelogs. It's just boring files all the way down. In Git, every object (file, tree of files, commit with a tree of files & parent commit(s)) are represented by hash. The data itself is stored somewhere -- in an interchangeable format (currently two formats are used: blob and pack with index). Storage is somewhat decoupled from toolkit. You can even fix a broken repo by literally copying in file(s) with proper content. But the true power comes from somewhere else: you can envision defining own data types, beyond files, trees and commits, and plugging them into Git. And having them play along with the usual ones. A general content-addressable storage :D (Too bad Venti [1] was invented a bit earlier) I believe Fossil (the DVCS [2], not the FS [3]) comes pretty close to that, too. -- [1] http://en.wikipedia.org/wiki/Venti http://en.wikipedia.org/wiki/Venti [2] (the DVCS) http://en.wikipedia.org/wiki/Fossil_(software) http://en.wikipedia.org/wiki/Fossil_(software) [3] (the FS) http://en.wikipedia.org/wiki/Fossil_(file_system) http://en.wikipedia.org/wiki/Fossil_(file_system)

zb 16y ago

He doesn't seem to be claiming that Git is more revolutionary than Mercurial/Bazaar/&c. as a VCS. I think it's fair to say that Git makes it easier to build some system other than a VCS from it, since all of the low-level commands for directly manipulating the repository are exposed in the shell. Contrast that with Mercurial, which doesn't even have a Python API. (For the record, I have actually built such a system on top of hg, and I'm pretty familiar with git.)

j_baker 16y ago

I think it boils down to difficult to quantify factors: most notably, love. In spite of all of git's warts (or perhaps even because of them), it's very clear that git is a tool that was created by the people who would be stuck using it. I'm not saying that isn't true about the other ones. I'm just saying it just doesn't shine through as much.

deleted 16y ago

[deleted]