5 ms·

It also tells you how quickly software employment has exploded, that so many (half? more?) developers have never used any version control (fundamental) tool oth

It also tells you how quickly software employment has exploded, that so many (half? more?) developers have never used any version control (fundamental) tool other than one that's been common for only a decade. As recently as the first dot-com boom, Git didn't even exist. Even Subversion was brand new, and it was mind-blowing how much easier it was to work with than CVS. One aspect of history that this article glosses over is that Git is not the only or even the first third-generation version control tool created. The earliest buzz I remember around DVCS was for darcs and bazaar, neither of which I've heard mentioned since about 2009. Mercurial and Git were released around the same time as one another, and were in a vim-emacs sort of grudge match for a few years before Git became the clear winner. Mercurial seems to still be in use in some odd corners of both the corporate and open source worlds - probably a legacy of people choosing it for projects during that period before Git "won". When I first tried it it felt a lot like Subversion made distributed. Nowadays it feels incredibly clumsy next to Git.

cesarb 8y ago
Don't forget monotone, which can be thought of as git's direct inspiration. The main difference being that monotone was painfully slow, while git was blazing fast.
muxator 8y ago
That's not true, in my experience. Mercurial has exactly the same features - and maybe something more - than git, with a UX which is at least more consistent. The main problem I see with mercurial is that its team stays too quiet: everything is so smooth that probably nobody feels the need of doing much fuzz about it. The HN community has a high technical level, but during my career, out there in the world, I have seen a lot of different folks: people that constitute the bulk of the workforce often do not have a strong mastery of the tools they are required to use. Sometimes they just endure them. For these people, using an easier tool (and mercurial is a good candidate in my experience) could probably help them to really improve their skills and become more productive team members.
- peatmoss 8y ago
  Back in the day, once I’d understood the value of decentralized revision control, I was convinced Mercurial would prevail, and that Git would become a footnote in history. This is one moment in my past that was formative in helping me make good tech predictions. Namely, if I see a technology that I think is better, and I think it will win out over an inferior technology, I simply reverse my prediction and enjoy being correct. Coming from Subversion, Mercurial made so much more sense than Git. I still think the CLI is more consistent. I keep hoping for a new shakeup in revision control systems, though I suspect such a change will be a long time coming.
  - skinnymuch 8y ago
    Isn’t a big part of Git overwhelmingly “winning” is Linus making it? The same sort of situation won’t be true in many other cases.
    - lsh 8y ago
      No, I don't think so. I think git "winning" was due to github.
      - kasey_junk 8y ago
        Specifically github made public repos free & private paid. Bitbucket did the opposite...
- JackCh 8y ago
  To be blunt I don't believe Mercurial has reason to still exist. It's feature advantage over git is very marginal at best, and it simply lost on popularity. If you ignore the inherent value in popularity (popularity means you spend less time training new hires who aren't new to the industry), then Fossil wipes the floor with Mercurial and Git in terms of features. In my view, the legitimate choices for FOSS version control these days are git (good enough, and popular) and fossil (featureful and obscure.) Why you would ever pick mercurial instead (marginally better than git, but almost as obscure as fossil) is completely beyond me. It occupies an uncomfortable middle ground of mediocrity. https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v... (The one caveat here is that Fossil may not be appropriate for very large scale decentralized projects, but frankly that's a problem git and mercurial are solving that most companies don't have.) (Incidentally, editor extensions for git have almost eliminated my CLI interaction with git. The UX of vim-fugitive is great, and similar extensions exist for just about any modern text editor. I think CLI UX is becoming less and less relevant when it comes to version control.)
tedunangst 8y ago
A lot of software was also developed without the use of any version control.

cesarb 8y ago

Don't forget monotone, which can be thought of as git's direct inspiration. The main difference being that monotone was painfully slow, while git was blazing fast.

muxator 8y ago

That's not true, in my experience. Mercurial has exactly the same features - and maybe something more - than git, with a UX which is at least more consistent. The main problem I see with mercurial is that its team stays too quiet: everything is so smooth that probably nobody feels the need of doing much fuzz about it. The HN community has a high technical level, but during my career, out there in the world, I have seen a lot of different folks: people that constitute the bulk of the workforce often do not have a strong mastery of the tools they are required to use. Sometimes they just endure them. For these people, using an easier tool (and mercurial is a good candidate in my experience) could probably help them to really improve their skills and become more productive team members.

peatmoss 8y ago
Back in the day, once I’d understood the value of decentralized revision control, I was convinced Mercurial would prevail, and that Git would become a footnote in history. This is one moment in my past that was formative in helping me make good tech predictions. Namely, if I see a technology that I think is better, and I think it will win out over an inferior technology, I simply reverse my prediction and enjoy being correct. Coming from Subversion, Mercurial made so much more sense than Git. I still think the CLI is more consistent. I keep hoping for a new shakeup in revision control systems, though I suspect such a change will be a long time coming.
- skinnymuch 8y ago
  Isn’t a big part of Git overwhelmingly “winning” is Linus making it? The same sort of situation won’t be true in many other cases.
  - lsh 8y ago
    No, I don't think so. I think git "winning" was due to github.
    - kasey_junk 8y ago
      Specifically github made public repos free & private paid. Bitbucket did the opposite...
JackCh 8y ago
To be blunt I don't believe Mercurial has reason to still exist. It's feature advantage over git is very marginal at best, and it simply lost on popularity. If you ignore the inherent value in popularity (popularity means you spend less time training new hires who aren't new to the industry), then Fossil wipes the floor with Mercurial and Git in terms of features. In my view, the legitimate choices for FOSS version control these days are git (good enough, and popular) and fossil (featureful and obscure.) Why you would ever pick mercurial instead (marginally better than git, but almost as obscure as fossil) is completely beyond me. It occupies an uncomfortable middle ground of mediocrity. https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v... (The one caveat here is that Fossil may not be appropriate for very large scale decentralized projects, but frankly that's a problem git and mercurial are solving that most companies don't have.) (Incidentally, editor extensions for git have almost eliminated my CLI interaction with git. The UX of vim-fugitive is great, and similar extensions exist for just about any modern text editor. I think CLI UX is becoming less and less relevant when it comes to version control.)

tedunangst 8y ago

A lot of software was also developed without the use of any version control.