It's GitLab, not MercurialLab. Hope they realize this and refuse to merge. I really like shared tooling and knowledge, so if Git dominates everywhere, all you have to do is learn git and that's it. It's a significant overhead to learn yet another VCS just because it is a little nicer. I hate wasted efforts.
I've been a Git user since 2007, but I disagree that we need only one VCS. Like another poster I've been through many variants over the years, from no VCS to using two copies (devel and stable) to SCCS to CVS and so on. CVS was fantastic compared to SCCS (because we had more than one developer, and we were already separately located), likewise Git is heaven compared to CVS.
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 up voted you because I think it's a shame that people down vote for having a strange point of view. I'm assuming you aren't trolling :-) Having said that, I completely disagree ;-)
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.
Yes, Exactly! mercurial is not THAT MUCH better, so it doesn't worth spreading. If it contain good ideas, we should try to incorporate some into Git, instead of making every tool more complex.
Yes, Exactly! mercurial is not THAT MUCH better, so it doesn't worth spreading.
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://qqrl.tk/item?id=6713742
By the same token, why have multiple programming languages? We can just use C. Why have different operating systems, we can use Windows for everything.
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.
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.
A sane user interface without page length manuals how to recover a working copy, that usually end up with nuking the work directory and doing a fresh git clone instead.
> It's a significant overhead to learn yet another VCS just because it is a little nicer.
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...
Completely unrelated side note, but there is actually something called HgLab. It might even be older than GitLab? I came across it much earlier than GitLab anyway. It is a shame it didn't really take off, I've always preferred mercurial over git and my company requires us to self-host.
Have you looked at RhodeCode ? It's very similar like Gitlab with free Community Edition version that is also open-sourced. It's dedicated for self-hosting.
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.
Yes! Absolutely! So I can focus on innovating where it matters (the product I'm developing). It alao would mean those things would be extremely polished (because a lot of people affected and interested to make it good). Also I would not need to learn so much random stuff I don't really care about.
In my experience, every time I've encountered someone who has this point of view, what they really mean is "Yes, we should have one way to do it, and it should be the way I like".
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.
I'm not saying this because of my rigid opinion, but because of productivity. I WISH Mercurial was the one who caught on, because everyone says it's better, more intuitive (oh, and it's written in Python which I absolutely love) but this is not the case, Git won and people should accept that.
To put another way; I HATE git, I LOVE Mercurial, but Git won, it's ubiquitous and Mercurial is not that much better.
This level of rigidity would preclude the gradual adoption of newer workflows, and hence be a hard blocker preventing any improvement or advancement.
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.
You're free to choose a tool and use that so you can focus on the product. But only having one tool would be rather counter productive for the community as a whole.
Gcc for the longest time was the only open source C/C++ compiler. It worked fine, but you really could not consider it "polished", despite a lot of people being affected and interested to make it good. It wasn't until LLVM came around that it got better.
Having one thing doesn't ensure at all that it will be polished. In fact, it's more likely that it will stagnate.
Git and Hg is similar, but that is not all there is to the DVCS space. Fossil target a different use case. Darcs have an entirely different underlying structure, which enables different abilities, especially during merging. I find it hard to believe that a single tool can be the best for
* Huge monorepos and thousands of developers
* Repos with huge binary files
* Repos with few developers
* Personal repos.
* CD repos
* Interconnected repos
Even if two different repository technologies are more or less equivalent, some things might be too cumbersome in one but not the other.
Sytse is quite active on here - wondering if he will comment about this?
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"
