But even though I'm using Git for everything, we need Mercurial. And any future new VCS system with new ideas. Otherwise we won't know what's possible, where leaps can be achieved. Git didn't come out of nowhere, Linus put together the first version in just a week - he put down the fundament, the basic ideas that Git is built on. The reason he could do that was because he had used Bitkeeper previously (before Bitkeeper he refused to use any VCS at all), and his experience with Bitkeeper enabled Linus to come up with the Git fundamental principles (note that Git is different from Bitkeeper in important ways - particularly the core, where Bitkeeper built on (basically) SCCS and Git has a totally different way of tracking changes).
Git (and Mercurial etc) are what they are precisly because there have been other version control systems before them.
I've used RCS, CVS, Source Safe, Perforce, bzr, subversion and git professionally as a programmer (and that's not including home grown VCS systems that nobody has heard of). I like git, but it's hardly going to be the ultimate VCS ever in the history of the universe.
I remember using RCS and switching to CVS. You have no idea how happy I was! It was like night and day. When I eventually started using distributed VCS systems I had that same feeling.
We need a variety of systems where people are pushing the boundaries in order to get to the next level. I don't think Mercurial is the next level, but there are some really good ideas in it. Sticking to a single implementation will hold our whole industry back.
To be fair, learning a new VCS takes as much getting used to as changing the colour of your sneakers compared to all the other stuff you have to learn in your career. If you hold on too much to a small little island of technology, you could find that the rest of the world passes you by pretty quickly (Speaking as a fairly old guy, a lot of my former colleagues are in that predicament right now -- it's not fun).
RCS provided revision control CVS provided concurrent checkouts by different users Subversion allowed moves and renames and atomic commits git is distributed.
Each one of those was so much better than the previous one that it replaced the previous one, despite that previous one being ubiquitous.
Mercurial might be 5% or 20% better than git, but it doesn't matter. It's not 300% better.
Mercurial won't take over after git, in the same way KDE won't take over after Windows. The next thing has to be the iPhone - the thing that changes the paradigm completely.
But it is better; just how much depends on the situation. If you were the guy who blew away a bunch of Jenkins repos using a “feature” of Git, you might feel differently--https://news.ycombinator.com/item?id=6713742
I'm actually super happy about mercurial support. Git is very complex and that complexity is a real barrier to entry and a time suck when a beginner invariably screws up. And if you feel comfortable with your git Fu, please explain to a beginner how to recover lost commits using git reflog or when you would use an octopus merge.
git reset --hard
C is just terrible, it has to be improved, but the "Git vs Mercurial" is not the same topic, because Mercurial is not THAT MUCH better to worth to replace it or make thing more complex.
Then keep using Git and let others that want to use Mercurial do so. To be honest, it's not clear what your argument is. You use Git so everyone else should use Git?
Almost everyone is using Git nowadays, so the rest should use Git also, yes, instead of wasting brain cycles, even worse huge efforts to support Mercurial instead of improving existing features in GitLab.
I'm not at all against progress, innovation or opinions, but I hate complexity, wasted effort and somebody forcing me to learn yet another tool just because...
* Huge monorepos and thousands of developers
* Repos with huge binary files
* Repos with few developers
* Personal repos.
* CD repos
* Interconnected repos
I hesitate to criticise it, but I don't think such an environment would be polished. A frozen environment is one which can't be improved, so will naturally stagnate. You couldn't achieve a state of being "extremely polished" because those who cared to do the polishing would be denied the ability to do so because it requires change in order to do so.
The obvious counterpoint to your statement is that if your mentality held sway, we would never have had Git and would still be on SVN.
To put another way; I HATE git, I LOVE Mercurial, but Git won, it's ubiquitous and Mercurial is not that much better.
Having one thing doesn't ensure at all that it will be polished. In fact, it's more likely that it will stagnate.
Hg and Git are both GPLv2.
Even if it's not the best way. If it's for more than one person, for the sake of sanity, pick a single way to do normal tasks. It doesn't have to be static (changes to the process/tooling can be trialed and applied), but it should be single.
I've built developer tools for big teams that improved productivity and increased my and others' happiness for a living. And I'd shred every single commit to those tools in a heartbeat in exchange for an environment where you don't have to head-scratch about what process and tools other people were using to make changes to the same code.
Edit: if you look in the link it seems he has made a comment on the issue:
"This is really interesting. We need to make sure that by integrating Mercurial we do not slow down the future progress of GitLab. Now that we have a clean abstraction with Gitaly 1.0 coming in 11.3 this is a good time to look into it"