Mercurial may not be popular, but the people that love it really love it. There was much sadness when Bitbucket discontinued support. Maybe Heptapod is a place those people can go.
At least there's somewhere reasonable to host your code but the thing that made me switch from hg to git was the ecosystem surrounding it. For example - on TeamCity you can just upload your SSH private key to the UI, for Mercurial you've got to configure something directly on each build agent.
Much as I loved it, I was keenly aware that I was a second class citizen without access to the integration or the mindshare. Also, git really isn't all that bad but I do miss Mercurial, I think it deserved to win.
`hg` used to be my go-to DVCS, then the GitHub wave hit and pretty much `git` on the job everywhere. Although, my first job out of Grad School did use mercurial, but eventually moved to GitHub Enterprise.
I do miss it, and I hope mercurial continues onward.
I wonder if anyone out there has an opinion on whether there is a smaller tool inside of Mercurial waiting to break out, the way Firefox was a renaissance for Mozilla.
That seems to imply there’s some problem with hg the tool, being big and bloated? In my experience the tool is fine (quite a lot better than git, IMO) - the problem is that distributed version control is all about community, and the community uses git. Mercurial-the-tool would need to be 10x as good to get people to consider leaving git’s community, and it’s only 2x as good, so they don't.
It’s nice to see another option for mercurial. Heptapod will definitely help given an integrated CI/CD.
In my startup everything is mercurial. It’s miles ahead of git when it comes to user interface and experience with conceptual integrity.
Git is popular due to GitHub, for us we use self-hosted kallithea-scm [1] to provide workflow with pull request and review similar to GitHub. So far didn’t see the need to change, it’s just that we need to build our own small extension to integrate with CI/CD (here also buildbot [2] is quite nice). Another open source is sourcehut [3].
Sourcehut is a really well-engineered and well-run project. The architecture is SCM-independent, so Mercurial is not disadvantaged.
The lead developer goes out of his way to support less-popular systems, such as *BSDs and Mercurial, so if you work with more niche technologies, you may find Sourcehut a good home for your projects.
Sourcehut is indeed well engineered and well run, and also very opinionated - which is actually great for most people.
However, if the opinions disagree with you -- e.g., if you need your builds to run on Windows, you ARE disadvantaged. Which is not a bad thing - I wholly support Drew's machine and opinions - but that's one of the reason I can't promote it at $MY_DAY_JOB, where I can't drop the Windows requirement.
We use this. It's much better then bitbucket. We are a distributed team of about 15ish devs. It has had some growing pains, but the support team is top notch and extremely responsive.
"Gitlab has been one of the fastest growing platforms in the past couple of years. It has a strong feature set praised by many. We have seen all kinds of users switching from Mercurial to Git just to be able to use it. So the quality and the reputation of the product itself made us look into it.
Moreover, Gitlab has an open source version "Gitlab CE", provided under an MIT license. They have a healthy community with significant external open source contribution. It fits with our own open source philosophy and allows us to directly hack on the product core to add support for Mercurial.
Also, other open source communities, Gnome and Debian, picked Gitlab as their tool. Having such serious actors of the free software world trust Gitlab was important in our choice."
Can someone enlighten me as to the advantage of sticking with Mercurial? I've tried hg many times and personally found nothing compelling about it compared to git workflows.
Git is ubiquitous, there's no really important feature set that hg offers over git, and it's super trivial to convert repos from hg -> git. So why go through this effort?
Note: I'm not trying to start a flamewar; genuinely curious.
Mercurial is great at an org with lots of junior devs, because people really have to try hard to mess things up compared to git. It's very bad if you want to attract people who feel comfortable with git alone (despite the fact that they'd do quite OK with hg), and it's especially bad if you are trying to fit with very standard types of CI, which for the most part have close to no support for mercurial at one point or another in the chain. And you might find that out a bit late into the process and end up paying a steep price ("Hello Gitlab? yeah I'm gonna have to set up a local secured Jenkins instance to do this and that before sending you the rest" type of thing)
Recent-ish stackoverflow survey (2-3 years ago) also indicated that hg is used even less than zip files amongst devs, and significantly less than git, so market adoption is a big hurdle and anybody joining you will have to deal with this-thing-they-probably-don't-know and tooling that might not handle it (e.g. Xcode).
However I think there's value in hg being training-wheels for git and a safe haven for a bunch of newbie devs, and we're talking about people who know and enjoy tech here so using any kind of vcs will at the very least enable your team to open up to more stuff. There's plenty of tooling and support to migrate to git if/when necessary, and IMHO Mercurial gets a much worse rep than it actually deserves.
As someone who only knows Git, needing to work on an open source project where you had no choice but to use Mercurial was a massive pain. I don't remember what happened exactly but coming from Git I managed to accidentally make a change somewhere but later needed to pull the latest changes and couldn't figure out the equivalent of rebasing and, when I got fed up with that, hard resetting for an hour. In the end I gave up and used git-hg to fork the repository, losing the ability to merge upstream, because I wanted to get things done and did not want the requirement to learn an entirely new VCS just for this one repository to hold me back.
But that's coming from me, who doesn't understand how Mercurial is supposed to be used. I felt happy when BitBucket announced they were sunsetting Mercurial, because of the miserable experience I had with that one single time and the fact that it would mean that all of the repository owners who forced you to learn Mercurial to contribute to their code would have no choice but to switch their repos to Git. But because I don't know any better I guess I don't understand what was being lost fully by losing Mercurial.
It's quite valid. I think the biggest hurdle is noticing that when you mess up hard with git the hurdles are affecting everyone down the line, possibly irreversibly. If you mess up with mercurial, the hurdles are affecting YOU locally really hard, possibly irreversibly.
That's probably why it's the main reason git people hate hg and hg people are confused about git, until they really mess up, and outside people view hg as much more limited than git.
I don't really have a side in any metaphorical battle because I've had to set up CI/CD for a mix of git and mercurial, but simply giving in to the social pressure of the tech world I've become more acquainted with git over time than with hg as a junior and I can see value in both.
However at a higher level (organization level especially), it's critically important to look at the trade-off that the choice gives you.
I'm trying to be objective here in saying that unless mercurial gains more traction in the world, fortunately or unfortunately you should stick heavily with git.
The only people who are unhappy with Mercurial are git users. Everyone I know who is coming from something else to Mercurial never have a desire to leave it.
It has a lot (most, really) of the power of Git, but no one has found a need to make an "Oh Shit Hg" site, because it's not trivial to screw up in it.
Because it has a separation between simple and advanced features (many of which are disabled unless you explicitly enable them), you don't get people wasting a lot of time trying to find the ideal workflow in Mercurial. In a sense it's a bit like Perl vs Python. Perl has many ways to do the same thing. Python is more opinionated, and has preferred ways of doing things. As a result, a team of N Mercurial users will usually not have N different workflows. In my current team, there's been a lot of thrash/arguments over the workflow (rebase vs merge, squash vs not, linear vs branched history, history rewriting vs not, etc).
The documentation, though, sucks. It's quite outdated.
Can someone actually mention the positive side of Mercurial specifically?
I'm getting bit by git so often and for those people who are barely programmers are also required to use git to commit their HTML/CSS stuff but once something doesn't work, I have to Google around and waste an hour trying to fix the repo and I'm all for willing to use something else if it's better but I know that people just simply jumped on it because of Linux/Linus name without thinking (kernel workflows are different than most people's but people only realized after feeling the pains) and the git's ecosystem is already far ahead of the others.
I even considered using subversion locally to push to central git but there is no such luck when the reverse is quite possible.
> Can someone actually mention the positive side of Mercurial specifically?
The workflow is faster for new users to learn, less concepts to grok, good GUI support, that's about it
> and for those people who are barely programmers are also required to use git to commit their HTML/CSS stuff but once something doesn't work
You would find that it's difficult to get non programmers to use hg even with a GUI, unless you have some very open minded people
> I know that people just simply jumped on it because of Linux/Linus name without thinking
Not true, so many git users have no idea who made this tool and don't actually care, all they care is that it's open source and suits most of their tasks
New users don't know but early adopters who advocated to spread the ecosystem and tooling surely chose git because it was used for the kernel and guessed that it would work for everyone.
New users never had any choice these days as their workplace is already using git.
> you don't get people wasting a lot of time trying to find the ideal workflow in Mercurial.
Interesting. I’m keen on trying Mercurial, but one thing that has somewhat confused me is the profusion of branch-like workflows. Named branches, bookmarks, now also topics (or whatever it’s called), hidden commits etc.
Is there a good definitive guide somewhere on the best workflows for hg?
Thanks for this. This is fairly old now though, and doesn't even mention bookmarks (which I understand to be like git branches, except they aren't (?) synched between repo copies. Then there's some new stuff that apparently are very good, but I can't find a proper description of how they work / should be used.
(I have not audited to see how accurate the information is, though).
> Then there's some new stuff that apparently are very good, but I can't find a proper description of how they work / should be used.
Yes - I often wished that someone wrote and maintained an article listing all the extensions that one likely will want to use.[1] One you may want to look into is evolve.
[1] Maybe someone has written this - I haven't checked in the last few years.
I personally use bookmarks. They're simple to use. However, people have issues using them in a team setting (by default it doesn't sync the bookmarks when there's a push, I think). I have not explored topics - looking at Heptapod it seems they prefer topics, so it may be the way to go.
If you're the only developer, then bookmarks should do everything you want.
I'm reserving judgement on HG but the comments saying it just works and is so easy gives me a good chuckle were I've had to set up all sorts that's non-obvious. topics not branches? cool ok. command not found, right uh enable extension 'topics =' yep sure obvious ok, Huh wired error now. oh pip install hg-evolve has topics in it fine ok.
go add a remote to an existing repo. lovely ux there.
and now you're telling me about bookmarks, I've a docs page open to read about phases, that seems kinda neat. at first glance thought it seems like a solved problem of protected branches and separate forks.
I find it more intuitive than git. I think it's especially easier to move, split or combine repos, but others will disagree. We used to use it at my company, but at a certain point, it had to be a forced effort to use as opposed to git, which is the default for most tools and incoming engineers.
Now that bitbucket support is gone, I agree it's not worth the effort unless it's already deeply integrated into your tools.
Version control is one of those things where a lot of the value comes from using what other people use.
By definition, version control is for collaboration, so using a less well-known version control system impedes the regular work of your project.
There's also the issue that version control is integrated into lots of other software. Everything now supports Git and Subversion, but support for other VCSes is rarer.
This is kind of unfortunate, because it makes innovation hard. Projects like pijul exist to try to move the state of the art forward, but it's difficult to see how they will gain adoption.
Facebook and Google may use it but it serves, more or less, as a front-end to something else. Especially at Google, where it is optional to use Mercurial at all.
To me as a daily Mercurial user, the biggest thing it brings is, in Git
parlance, a distributed reflog. It makes sharing of mutable history much easier
and safer.
Mercurial has the concept of changeset evolution [1] that tracks the
meta-history of changesets (commits): who re-wrote which commits at when using
what command. Stored as obsolescence markers in the obstore, this meta-history
is synchronised with remote repositories on pull and push.
Combined with a nice history rewriting UI provided by the evolve extension [2],
this allows some advanced collaborative workflows that are pretty awkward in
Git.
Suppose you developed feature x on branch [3] feature-x, and submitted it for
review. At the same time, you started developing feature y that depends on
feature-x on branch feature-y. When feature-x is integrated to master via a
rebase, you can run `hg pull` and `hg evolve`, and Mercurial will automatically
rebase feature-y on top of master. This also works when commits are edited,
squashed, split, reordered, or dropped. This gives reviewers more freedom to
decide what to accept, without having to worry disturbing contributors' work.
[3]: Using Git parlance to simplify things. Branches meaning something else in
Mercurial.
Now you've also pushed feature-y. This time the reviewer wants you to change
something. You changed the commits, and pushed feature-y again. Even without
force push, the server will not reject the push, because it knows from the
obsolescence marker that the new commits are not really new but are re-written
old commits. Again, this even works when commits are rebased, squashed, split,
reordered, or dropped.
While there is no commitment yet, now that Mercurial is gaining the ability to
operate on Git repositories, there are discussions on how to store obslog in
Git's store, so maybe that's something that Git will eventually have.
Another thing I like very much is that every commit in Mercurial is a standalone ref.
This makes a patch-based workflow a lot simpler as you don't need the ceremony
of creating and cleaning up branches. You also don't run into detached heads.
I prefer mercurial over git. The workflow and branching/merge process is a whole lot more intuitive to me. Git seems to have a million commands each with a unique set of args that can do very thing things.
Either way, they're both pretty similar at a high level and work great.
iIUC Mercurial is better for managing very large repos because it supports partial checkout. This large companies with monorepos are more likely to choose mercurial. Of course there are ways to modularize a large codebase in Git (submodules, Android's repo system) but they tend to be clunky and inconvenient.
> Heptapod is a community driven effort to bring Mercurial SCM support to GitLab™, started by Octobus, a company providing professional services around Mercurial.
What do search trends have to do with a community effort to bring fully featured open source version control tool support to dev-ops management software? Is your comment aimed at the sponsors?[0]
