Comment by cimmanom | Hacker News Reader

Comment by cimmanom | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

No, I don't think so. I think git "winning" was due to github.

Specifically github made public repos free & private paid. Bitbucket did the opposite...

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...

(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.)

Mercurial work flow is just so slick and natural and painfree....

Which noone has ever seriously claimed for git.

Mercurial + Mercurial evolution outcompetes git rebase workflows in a really nice slick reliable package.

Merges are so hassle free for me these days.

I feel that editor extensions for git are the future for 99% of git interactions. Git+[fugitive/etc] still may not be as slick a UX as Mercurial+[mercenary/etc] (I've not actually used any editor extension for mercurial) but it really comes close to closing the gap. To the extent the UX advantages of Mercurial really seem very marginal to me.

But when it comes to Fossil, nothing I've seen comes close. It's built on sqlite which I think turns off a lot of people who have prejudices against SQL, but sqlite is the furthest thing from a big 'enterprisey' RDBMS that give most users the shivers. It's a really tight piece of software, and in fact Fossil is created by the creators of sqlite and the sqlite project is managed with Fossil. So fossil's vanguard project (sqlite) has more deployments than even git's vanguard project (linux)! Mercurial has Firefox and Python, nothing to sneeze at; clearly it's a capable VCS, but I guess my point here is that Fossil doesn't get the attention it deserves whenever people talk about a FOSS alternative to git.

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.

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

Reply on news.ycombinator.com