Hacker News new | comments | ask | show | jobs | submit login
Adding Mercurial support to Gitlab (gitlab.com)
277 points by testcross 5 months ago | hide | past | web | favorite | 180 comments

I still don't understand why git became so popular in comparison to Mercurial. Mercurial seems like a much more friendly and sane system. I hope adding it to Gitlab will help its popularity.

Speaking as someone who used both Git and Mercurial, and who has used both to contribute to projects:

Git's concept of branches as simple names for commits, and the ability to switch branches really easily within one checkout (rather than encouraging the use of multiple working directories) helped hugely. Mercurial grew the ability to do git-style branching later, but git had it from the beginning.

Git has always treated performance as a first-class feature, and that has enabled certain types of workflows that Mercurial makes painful. Git is fast enough that many things don't feel like they take any time at all.

Git integrated first-class support for carefully constructing and reworking a set of patches to be sent by email. Mercurial again eventually grew such support, but early on, it was much more insistent that all branches must be kept around, and by the way are you sure you don't want to push your development branch experiments up to the server and keep them there forever since you haven't merged that head into the mainline?

Even later on, mercurial had more of the functionality people wanted but relegated it to "extensions", while Git shipped it out of the box.

Take a look at https://walac.github.io/mercurial-for-git-lovers/ (from 2015) for just one of many examples.

About 5 years ago I introduced multiple developers for DVCS, as we migrated away from TFS. I was used to Git, so we used it for a while because we might as well support the tool with the most traction. But after I had to unravel the state of a repository to save work for the 100th time, I assembled a small team to evaluate it. Our conclusion was clear, Git was not working. We rolled out Mercurial for a few projects and it just clicked for the guys, they even began using advanced workflows without central repositories.

So while it might be obvious for you why Git became most popular, I believe that today, it continues to be that way mostly because of GitHub.

I spent a lot of time getting a distributed team that was on a terrible proprietary source control system onto mercurial. Being able to just have them force push their changes and then fix it on my end was a great way to get people on board with it, while my experiences getting a team onto git included a lot of lost code.

> Git's ... ability to switch branches really easily within one checkout (rather than encouraging the use of multiple working directories)

As a heavy Mercurial user, but only for the last couple of years, I'm confused by this one. You can just as easily switch between branches (in the Mercurial sense) and bookmarks (which are Mercurial's name for Git-style branches). How did that used to be different?

In fact one of the nice thing about Mercurial is that you can easily switch to any commit and you don't need to choose between a hard reset and a detached head, because you can always make a commit anywhere (multiple heads for the same branch) and it will never get garbage collected (a foreign concept in Mercurial). Mostly this is good because you simply never need to understand what these concepts mean, which it turns out are not fundamental to DVCSs. But also this makes a neater alternative to stash (although stash is also available): just commit your half-finished changes, mark the revision "secret" (which means it won't be included in any push), then switch to another revision. You can always strip or rebase the revision later, so long as you haven't pushed it (admittedly these actions do require extensions, but they're included with all Mercurial installations).

Our workflow at work (with Mercurial) revolves heavily around multiple heads for a single branch and relating the commits to a JIRA issue is done by simply putting the issue number in the commit message. So we have (unnamed) feature branches and also no bookmarks for them. You just start from the latest release tag and create new commits. No need to think of a name for the feature branch, or telling the reviewer or issue tracker which bookmark belongs to that issue.

This might be mainly habit and familiarity with a different tool by now, but to me it's simpler than equivalent Git workflows as there's less ceremony involved to start working and there's no fear around accidentally losing commits because they don't belong to a branch (I kinda hate having to go into the Git reflog to find commits that are temporarily lost because they don't belong to a branch).

Well that is just about the strangest workflow I've heard of. It sure seems like you are throwing away a lot of the power of the tools to do things manually. Honestly, I don't see the point.

I've used Mercurial from the very beginning, the branches are great and bookmarks are fine. I see no reason why you wouldn't use them.

We use both, just not in the way a typical git workflow would use feature branches. Basically those are all anonymous heads on the same branch for us; a workflow that is probably as alien to git users as naming each and every head is to Mercurial users.

Bookmarks are a relatively recent addition to mercurial, but as you point out you could always easily switch to any commit. It's just that people didn't understand how to work that way early on. The recommended flow of mercurial in the early days was to have a clone per anonymous branch, or to use named branches, if I remember correctly.

We as a community of developers have learned a lot about the power of DVCS since git and mercurial got started. I'd say even the developers of those two tools have learned a lot since then.

>We as a community of developers have learned a lot about the power of DVCS since git and mercurial got started. I'd say even the developers of those two tools have learned a lot since then.

So are we going to have something better than both hg and Git? There hasn't been any new DVCS for a long time.

Pijul, hopefully

With agpl licence, it has a reduced chance to become mainstream, though.

It's a pity, because I like its technical ideas.

For small teams with a simple code-base Mercurial is a way to go. Being written in a readable language is just a cherry on top. If you eventually need those fancy features that Git provides you could always migrate later.

I'm a huge Hg fan, and this thread makes me miss it terribly, but being written in "a readable language" is pretty much negated by all of the shenanigans Mercurial has to pull (including a nontrivial amount of C and Rust) in order to be passably performant.

What is hg's underlying data model?

Abstractly, it's exactly the same as git. Commit → File tree → File data blob.

The underlying data structures used are different, but considered an internal detail, so could be changed in the future. Today, most data is stored in a "revlog", where data can be either be stored (compressed) directly or stored as a (compressed) delta against an earlier version. Deltas may be chained. The index consists of fixed size records, which gives fast lookups, which are also linked to global revision numbers so that you can eg quickly find the commit based on a specific file change.

Obs: This is based on attempting to re-implement the basics of Mercurial from scratch.

I'm not an expert in mercurial, and I'll defer to those who are.

My understanding is that while Git stores a tree of objects indexed by hash (and then packs them into packs along with an index, which can be repacked arbitrarily later on), Mercurial's primary data format is a log-structured list of revisions as deltas.

My impression was always that Mercurial wasn't entirely stable/reliable.

Especially the Windows port seemed rather prone to corruption.

>Especially the Windows port seemed rather prone to corruption.

Quite the opposite of my perception.

I started with git. Then I got a job and for a while I worked only in Windows. At the time, I looked into git for Windows, and while everyone said it was stable, everyone also said that it was unofficial - the Git development team had stated clearly they were not interested in maintaining a Windows version.

I didn't want to be in the position to justify an unofficial tool to my employer, so I looked at Mercurial - Windows support has been in there since the first day. So I switched to Mercurial. In almost a decade of using it on Windows, I have never had any problems.

Mercurial is great - I've never come across a use case where git is clearly better.

Unicode file names were a bit of a pain at one point. Haven't tried that again recently.

Having a local "bare" copy (to use Git's term; `hg clone -U`) of the Mozilla repo, I'd like to create a checkout of it (`hg clone`), and build Firefox from it.

This results in 90 minutes of waiting with hg pegging one CPU core (CPU-bound, not disk-bound!), then a few minutes of hg actually writing files, then the actual build taking 60 minutes.

In the git community, it was always taken as a sign that they were doing something right that `git clone` was faster than `cp -r`. I'm having a hard time not taking it as a sign that Mercurial is doing something wrong that `hg clone` is so much slower.

edit: The saying was that `git checkout` is faster than `cp -r`, not that `git clone` is. The sentiment stands.

Mercurial tries to use hardlinks to share as much actual repository data as possible when doing a local clone. Maybe that's the part that's interfering here. You can try using hg clone --pull instead of just hg clone, which will not do hardlinks. Don't have much experience with terribly large repositories in Mercurial, though. Those we have at work have maybe a few thousand files and less than 20k commits and they're not particularly taxing.

`git clone` will also use hardlinks by default.

       --local, -l
           When the repository to clone from is on a local machine, this flag
           bypasses the normal "Git aware" transport mechanism and clones the
           repository by making a copy of HEAD and everything under objects and refs
           directories. The files under .git/objects/ directory are hardlinked to
           save space when possible.

           If the repository is specified as a local path (e.g., /path/to/repo), this
           is the default, and --local is essentially a no-op. If the repository is
           specified as a URL, then this flag is ignored (and we never use the local
           optimizations). Specifying --no-local will override the default when
           /path/to/repo is given, using the regular Git transport instead.

How long ago was this? And what OS? I know we're faster than unzip on some platforms, but IIRC we just found a pretty awful performance issue on...linux? I think?... that meant our parallelized approach to writing files was burning a ton of time in the kernel filesystem locks or something.

Just a few days ago. Parabola GNU/Linux-libre (like Arch Linux). On btrfs, if that makes a difference.

From what I could tell, whatever the slow part is, it wasn't parallelized at all; of 16 cores, 15 were idle, and 1 was pegged at 100% (and very low disk-wait).

I've been meaning to dig in to this more. I'd tried adding --stream, figuring that maybe it was re-compressing the entire repo; but that just lead to a warning about "server doesn't support streams" or something like that. I'll definitely try ygra's suggestion to try --pull, and if that doesn't yield good results, I'll actually dig in to the sources and see what's going on.

Sounds a lot like https://twitter.com/indygreg/status/1028097388261433344 - I'm pretty sure Greg was working with hg when he noticed this issue.

In any event, if you're enthusiastic about this kind of thing, we'd love to have more eyes on making hg checkouts consistently fast, even in the face of filesystems undermining those efforts. ;)

If it were just btrfs being silly, I'd expect the high CPU usage to be attributed to a kernel thread, not to the hg process. But we'll see :)

I have pulled and built Firefox from scratch over Australian internet in less than half that time? In general I have found all Mozilla repos to be an order of magnitude faster for this type of operation than the equivalent Google/Chrome repos (not using build caches).

The actual network clone is faster than that. The slow clone that I'm speaking of is cloning from one place on my hard drive to another place on the same hard drive.

How is git clone faster than `cp -r`?

My first guess would be that git is going to be faster since it won't be doing a huge number of stat() calls and similar to grab metadata about the files it's creating, instead git will have the data in a single data structure it can efficiently ask for it from. Of course the filesystem has this too, but git will have it in a single location and probably more compactly, leaving it able to do it all with fewer reads. Then it has the data in the files compressed so the read is faster too. All this should mean that git can get to writing the files faster than cp will.

It may be in relation to when you duplicate a repository.

When you cp an active git repository you receive an identical file state; when you git clone you receive only what is necessary. Old objects, reflogs, et al aren't in the clone. A clone of an existing local repository may also make hard links, if your file system supports it.

The battle seemed to be between Bazaar and Mercurial for so long. Both were easy-ish to use and both were written in Python.

Mercurial usually had the speed advantage but then git came along and wasn’t written in Python. Speed wise it blew Bazaar and Mercurial out of the water.

It was harder to learn for someone used to svn, perhaps, but the sheer weight of both Linus and Linux made it hard to ignore.

I think GitHub deserve a lot of the credit for git’s omnipresence, though. With Launchpad our aim was to create something bigger than “just” a code sharing site and fairly or unfairly both Launchpad and Bazaar were seen as too close to Canonical. Whereas GitHub picked up the mantle that Sourceforge had dropped and made something way more collaborative than Sourceforge but held onto the idea of being a neutral third party.

> Speed wise it blew Bazaar and Mercurial out of the water.

Benchmarks for this are hard to come by, and are for versions that are considered quite outdated now. But from what little there is, there wasn't that much of a performance difference between git and hg. For example, see this: https://www.draketo.de/proj/hg-vs-git-server/test-results.ht...

Fair, but that misses a bunch of short-running simple operations where hg does badly; things like "print the repo root" or "print the current branch name" take several milliseconds in Git, but Mercurial needs an order of magnitude longer (see e.g. https://www.mercurial-scm.org/wiki/OxidationPlan for some description of the issues there). Doesn't seem like much, but those add up, especially when they're wrapped up into other scripts that might run several of those in sequence.

Yes, there is a penalty of starting and stopping the Python interpreter every time, which is why they want to implement the front end command in Rust. For scripts, current users are better off adapting to the current hg ecosystem, and writing their scripts in Python.

Thanks for the link. I was not aware that hg on windows was that painful, plus all the dll hell that makes it hard for Rustification.

Well, sure they’re outdated because we’re talking about stuff that happened at least ten years ago.

As for benchmarks, I don’t have any but there’s plenty of anecdata elsewhere in this thread that echoes the idea that git had significant speed advantages over both bzr and hg.

>both Launchpad and Bazaar were seen as too close to Canonical

I think it's more that Launchpad is terribad. No matter how much I used it, I struggled to get to the code so I could read it. It looks like it's been somewhat fixes now with a small "Browse the code" link on the project landing site. It used to be like 4 clicks if you knew what to look for.

And when I used bazaar (on Arch in 2004 trying to contribute to Exaile), it would pin a core and make no progress. I didn't look at it again.

Bazaar... now there's a name I've tried to forget.

I think my history went something like this:

RCS -> CVS, CVS -> SVN, SVN -> Darcs, Darcs -> Mercurial, then Mercurial -> Git.

Bazaar I had to use for interactions with Ubuntu, but never in a serious way. Similarly I used a few other things such as Visual Source Safe (shudder), SCCS, and even BitKeeper, but I think they were used quite shallowly.

Mercurial and git started the same month.

I used Mercurial as my main DCVS (and even pushed it at work) for many years, but now I faced the fact that git won and use it for everything. I have to use git anyway, so I might as well not deal with two different workflows and use git exclusively.

Mercurial was ahead of git for a long time as far as usability and documentations were concerned. I still think it's a better match than git for many uses cases. Mercurial makes the simple stuff simple and the complicated stuff complicated (although still achievable), whereas git is more of a mixed bag in my experience. Git was superior for very large projects with many contributors working on completely different features and sending each other patches by email (e.g. the Linux kernel) but in practice 99% of projects, both FLOSS and corporate, don't have this profile. Git is a formula one, mercurial is more like a comfortable Sedan, so to speak[1].

I think git made it mainly because it could boast hosting the Linux kernel development and all the cool kids were on github.

[1] Which reminds me of this "Git is MacGuyver, Mercurial is James Bond" comparison which is probably widely out of date by now: https://importantshock.wordpress.com/2008/08/07/git-vs-mercu...

As someone who did a presentation on DVCS for the local PHP devs in 2008 I have no problem understanding that. I covered Git, Mercurial and Bazaar. Even back then I predicted that git will win. It might not look very user friendly, but the foundations were rock solid. Branches on Mercurial seemed very clunky compared to git's.

While I don't consider myself a wiz, I'm fairly proficient at both (was responsible for stuff like lfs and submodule reorganization on git in my previous job). I'm honestly surprised that someone adept at one would struggle with the other: you basically just need to understand the semantical differences in branching. On windows, hg plays much nicer with powershell (ok, so clean is an extension, otoh hg -nu | rm).

It's not even that - it's mostly just the commandline interface needing you to learn several arcane commands to do simple operations.

Of course, if you understand the underlying data model, they seem far less arcane, but that's the problem with Git that Mercurial doesn't have - you really need to understand what's happening under the hood to get proficient at it, whereas Mercurial has a far saner interface that hides the internals under a better abstraction.

I really don't think that mercurial is very good at hiding the internals. Consider a common operation; asking for the commit history. If you type `hg log` you get something very close to a prettified view of the internal datastructure by default; a list of all commits in the repository, in the order they were added, each annotated with a sequence id that's an index into the internal list. So a new user has to learn:

* hg log by default doesn't tell them anything about the current code they're working on; it's just a dump of everything. To get the history of the current working copy they need to pass -f which they are learning in other contexts means "do something unsafe".

* hg gives commits sequence ids that can locally be used in place of the commit sha, but must never be shared across repositories.

In practice at Mozilla I have seen people run into both these issues, causing much unnecessary confusion.

I agree with this, but OTOH, in my experience git actually has a nice smooth learning curve for a little while until you hit your first 'wtf did did I just do' snag.

I just know on my team or 5 much less technical people, the concept of version control and how to do operations in Mercury was near impossible and it fell on one person to manage merging files with master.

Also, this was a distance learning course where the head institution (MIT Media Lab) was keeping a central repo of every location's additions, and the changes made the repo so big that we had hard caps on how much data we could upload.

Later on, it fell on me to introduce git to some colleagues. Just walking them through 'checkout','branch','merge','push','pull' got them on their feet and contributing to a repo. If they hit a wall, I could help detangle the knot, but at least we were in it together.

I think git became dominant because there's no MercurialHub

Bitbucket was the Mercurial equivalent of GitHub.

I think Github was way better than Bitbucket in its early days.

This is the correct answer. For some reason, the top-voted comment is some nonsense about Git's branching, which was never something I've desired or every found useful in a decade of rigorous daily use with both. To the contrary, git's branching model still trips me up all the time, specifically when I want to do things like list all the commits in the branch.

Basically the problem is that unlike Mercurial branches which are actually branches while git branches are just a pointer to a particular commit. That pointer has no knowledge about what other commits are in the branch and the pointer can be moved anywhere across the tree (even to unrelated commits) with ease. Apart from the reflog, it's basically not possible to ask about the set of commits in the branch. The best you can do is never ever move the branch pointer except forward and make a note of the branch that your branch branched off of so you can do things like `git diff my-branch..parent-branch` (`hg diff -b my-branch` iirc). And this is just one of dozens of git warts.

I use hg at work and git for open source. I can agree that GitHub and GitLab add momentum to git. Bitbucket is the almost the only provider. I feel hg can do the same things like git but a lot of that power is hidden under extensions in hg. I also love git releases that add a lot of UX improvements. Git is also fast compared to hg due to python startup time and it's one of the reasons hg still remains on python2. There is some effort on reorganizing python startup layout which will lay the foundation for faster hg. I hope with GitLab support hg gets more support and visibility.

Ruby and Rails were big at the time, and those communities really took to Git. There was kind of a competition between them and Python, so maybe that had some influence on not picking Mercurial/Bazaar, but regardless I think it wasn't as grounded in technical points as we'd like to think.

From chatting with various folks, I think git had some features before Mercurial did. I recently adopted hg and found it much smoother to use, but learned also that many of the features I depended on were added only very recently.

Simple, Linux.

This is definitely part of the reason. Back when git was first released there was a huge amount of scepticism about whether anyone actually needed it, but lots of people used it anyway just because they wanted to use what Linus made for Linux.

I think since then many people have realised that Linus was right and that git is good, but it just wouldn't have gained so much momentum without Linux.

I don't think people found git better than hg (or monotone), but it got a lot more attention (due to Linus) and using two different systems is a pain.

I would say a combination of things:

1. Network effects of github becoming popular. 2. It's faster. 3. Linux uses it and it was written by Linus (must be good in some people's minds).

In Windows Git allows to use non ascii letters for filenames.

We used hg in a uni project once, since large parts of our team had never used a VCS, and on of our advisors urged us to consider hg. (This was around 2010, so I guess hg improved considerably since then.)

Even considering the additional overhead, we switched to git after a few weeks since the repository was constantly broken, and the two of us that knew git and SVN were desperately searching for the consistency and tools we had in git. At least we could support the team from there on and make it work for them. Not the ideal solution, but the best available to us.

So I totally understand why git is more popular than hg. Until hg could be considered mature enough for larger teams, git already had a huge following, IMO.

Given that all of Facebook's repository's are hg based, I think it's fair to say that is pretty mature for large team use cases

Facebook didn't use hg until 2012 or later. I was talking and only know about the state of hg in 2010/2011 and at that point, git was widespread, stable and widely more useful than hg for anything besides simpler/smaller projects, again IMO.

Hg was pretty mature by 2007 when I started using it.

I used hg for years before finally succumbing to git. Never had a single issue with hg.

For a strong contender to "next-gen DVCS", I recommend checking out https://pijul.org/.

Written in Rust and based on a sound theory of patches. If GitLab actually merges Mercurial, I sincerely hope Pijul is next.

Pijul looks very interesting but unfortunately as it stands (and without a huge open source project à la Linux to back it) I can't really imagine it taking over git as it stands. It might be better than git but is it enough an improvement to justify the cost of switching? I'm not sure.

Now if pijul takes inspiration from Fossil and implements things like issue tracking as part of the DCVS then that would be an other story as far as I'm concerned. That would be a pretty radical upgrade from git.

> is it enough an improvement to justify the cost of switching?

This is the main question everybody should be asking about potential contenders [0].

For most places, switching would be a huge undertaking. Even if there's an import tool that works flawlessly (big assumption), you now have to potentially re-think all of your secondary tooling [1]. Not just 3rd party tools, either. You have to think about potentially tweaking build pipelines, etc.

Not to mention (re)training people which is very likely orders of magnitude more costly [2].

For any potential tool to overtake git, it will have to provide some pretty extreme benefits. Git originally provided some pretty extreme benefits over SVN and yet there are plenty of places that still can't justify the cost of even making that switch.

[0]: I'm only talking about contenders for large projects and/or business' ecosystems. Use whatever you want on your side projects.

[1]: GitLab adding support for alternatives is a good way to start mitigating this.

[2]: In more ways than just purely financial.

Heck there are places that use ClearCase still.

Companies that are at rest tend to stay at rest.

> Pijul looks very interesting but unfortunately as it stands (and without a huge open source project à la Linux to back it) I can't really imagine it taking over git as it stands. It might be better than git but is it enough an improvement to justify the cost of switching? I'm not sure.

Nailed it. And you could argue in an analogous way about all the cryptocurrencies that try to be "better" than bitcoin/ethereum (offtopic I know).

As far as code is concerned I fully agree. But DVCS tools have a much broader utility for content sharing (documentation, teacher's resources, screenplays etc.) that we've only just begun to explore.

My hope is that what will happen is that git sees what Pijul does and integrates some of it's innovations and copies them. I don't know how feasible this is though, technically.

That's not gonna happen. Pijul's innovations originated in SCMs much older than git, and Torvalds evaluated all those SCMs before deciding to create git, so he was well aware of those ideas. If it didn't happened in the beginning I doubt it'll happen in the future.

I would call it a "theoretically sound current-gen DVCS". Unfortunately, theoretically sound is no guarantee for success, quite the opposite.

cf darcs

I recall that one of the main problems with darcs is that it was almost comically slow even on moderately sized codebases. I suppose it might have improved later on but by then Git and Hg were too far ahead.

Darcs was plagued with speed issues. With just the "right" set of patches you could watch it spin for infinite amounts of time.

That said darcs was a pleasure to use, when it worked, and I have fond memories of it if I ignore the speed/corruption issues.

Part of the problem of darcs wasn't so much that it was slow (it was fast enough in most day-to-day operations), it was that it was hard to predict when it might be slow in a given operation. Slow performance across the board is something that you can solve at scale by throwing more hardware at it or producing warnings/progress statements for it (there are a lot of cases where you don't care how long something takes if it just gives you a well updated progress bar for it).

Slow performance under circumstances you and the app can't predict is a lot harder (an unwelcome relative of our good old friend, the Halting Problem).

On a shallow note, I hope the command is changed or aliased if this becomes mainstream - writing "pijul" at the start of every command is awkward on English keyboards given that all the letters are near to each other on one side. Writing "git" or "svn" on the other hand, the letters are spread across the keyboard and shared between hands.

You don't alias git to just g?

I don't have that alias, but I have a shellrc snippet for upcasting all Git aliases into shell aliases. For example:

  $ $ git config -l | grep checkout
  $ which co 
  co: aliased to git checkout
Source: https://github.com/majewsky/devenv/blob/f7eb66a52a67b9c43762...

And pijul naturally goes to "pj"...

It gives new meaning to working in your PJs.

That sounds identical to darcs' pitch - http://darcs.net/DifferencesFromGit

darcs was an absolute pleasure to use, right up until they got stuck on the "merge of doom" bug http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr...

I think pijul's algorithms avoid the "exponential merge problem", though I don't know the details: https://pijul.org/manual/why_pijul.html#better-conflicts-for...

Pijul is definitely inspired by darcs and from what I've seen most of its team is very familiar with darcs.

Warning that the UI is still missing a lot, even though the theory and basis should give it a lot of power eventually.

Mercurial is much easier to understand and use than git, and for the most part has feature parity with it. The only drawback was the decision to implement it in Python, which makes it very slow for large codebases with gigabytes in binary files. However, I'm given to understand that core performance parts are being re-implemented in C.

What's interesting is that Git is fast up until it isn't, and it's written in such a way that fixing performance issues that do pop up is hard (or extend the software when more custom behavior is needed).

That's why Facebook chose to just fix the slow parts of hg[1], rather than fix the slow parts of git, to build a VCS which would scale with its codebase.

[1]: https://code.fb.com/core-data/scaling-mercurial-at-facebook/

> That's why Facebook chose to just fix the slow parts of hg[1], rather than fix the slow parts of git, to build a VCS which would scale with its codebase.

On the other hand, Google seems to successfully use Git in the same way.

Google does not use Git for its monorepo.

Afaik Googlers can use git client-side. The central repo is certainly not git though.

Also parts of Google, like Chrome, Android, and Go, do use git.

Or Microsoft (Windows is using Git).

Microsoft wrote a new filesystem driver for git because extending the code itself was too difficult...

They also worked a lot on Git itself.

With extensions to make it bearable for their code size.

Just as Facebook does for Hg: https://bitbucket.org/facebook/hg-experimental

Several parts of mercurial are implemented in C. There is an ongoing plan to recode some of the core in Rust:


Recoding it in Rust would make Mercurial instantaneously unportable to any operating system which does not have a Rust compiler.

What kind of platforms would you be worried about missing out on. Rust platform support[1] looks pretty solid, but of course isn't that of, say, C, but in practice I am not aware of (but would love to learn about!) Use cases for running a vcs on more obscure platforms.

[1] https://forge.rust-lang.org/platform-support.html

"I don't recognize your platform.

Rust runs on Windows, Linux, Mac OS X, FreeBSD and NetBSD. If you are on one of these platforms and are seeing this then please report an issue, along with the following values:

    SunOS i86pc
    5.0 (X11)
To install Rust, if you are running Unix, run the following in your terminal, then follow the onscreen instructions.

  curl https://sh.rustup.rs -sSf | sh"
...and running that gives:

  curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
And I am running UNIX, a true, AT&T System V, Release 4.0 UNIX: Solaris 10 on i86pc.

I don't want to have to give up Mercurial just because someone somewhere is trying to be trendy by rewriting parts of it in Rust, because he thinks that's all the rage now.

That's a curl error to do with ssl versions, try using something other than curl to download it.

Actually, after a bit more research it looks like Solaris is a lower tier platform, which means there are no prebuilt binaries that are available, but it should work if you build it yourself.

I've been using Mercurial on Solaris 10 since 2006.

What you're saying is that if I had to upgrade to a newer version of Mercurial which used software written in Rust, I'd have to bootstrap and port an entire programming language, just to use a newer version of my revision control software?

That would be entirely up to the maintainers of Mercurial if they would distribute pre-built packages for Solaris 10. If you're concerned, you'd be better off making the case to them to do just that.

It's about the concept, not about Mercurial per se: nobody should be forced to have to bootstrap and port an entire programming language just to be able to use a newer version of an application. That's insane and irresponsible, not to mention selfish.

How strongly are you claiming "nobody" here? Does the cost of supporting niche platforms ever get too high in your mind? If so, what is an appropriate line to draw for cutting off explicit support?

Hopefully, it would increase pressure to actually port it there or to use another compiler like mrustc[0]

[0] https://github.com/thepowersgang/mrustc

> Mercurial is much easier to understand and use than git

I simply do not find this to be true. I've used git for years and tried to use hg to participate in a project and I straight-up just could not understand its branching model and how exactly I was supposed to use that tool. I ended up maintaining my work in a git repository and very carefully doing individual commits and a push in the hg repository only at the very end of a long work period. My daily work remained in git because I could not for the life of me understand how people work with that tool with regards to local branches and squashing. (Which, sorry, I cannot do without.)

> I ended up maintaining my work in a git repository and very carefully doing individual commits and a push in the hg repository only at the very end of a long work period. My daily work remained in git because I could not for the life of me understand how people work with that tool with regards to local branches and squashing.

Local branches are fairly simple - use the phase command to mark your changesets as secret.

As for squashing... It's more complex, and not so easy, though doable, because Mercurial discourages it. (Though the solutions are on their wiki [0], and various extensions can simplify it for you.)

[0] https://www.mercurial-scm.org/wiki/ConcatenatingChangesets

Use Mercurial histedit extension, this is a game changer on all operations. Works like git rebase -i but just better combined with phases. So most likely your not-yet-pushed commits are marked as draft, so you can run hg histedit.

We use this ALIAS:

histamend = !$HG histedit $(hg log -l1 -r '(draft() or secret()) and branch(.)' --template={rev})

This shows you option to drop/squash re-order/edit messages on all draft or secret commits in the current checkout branch

Or just use evolve + topics and you can squash/fold in pretty much the same way as git, plus you hg obslog you can still reference the root commits.

Mercurial is much easier to understand and use than git, and for the most part has feature parity with it.

There isn’t a Git workflow that can’t be done using Mercurial; in fact, the Mercurial team from what I’ve read and listened to via podcasts, has intentionally added features to accommodate Git-style workflows, since developers obviously like and are using them.

Hm. My understanding is that the git and mercurial worlds follow different workflows around branching, merging, forking, etc.

Does that cause a huge impedence mismatch in the UI? Or will they converge?

In the same vein, I wounder if it's possible for a single repo/history to be checked out with either tool. You clone with hg, I'll use git. We both merge with patches as a common language.

Disclaimer: only use git

bitbucket supports both as well

For a self-hosted option please check out RhodeCode has the first-class support of Mercurial, including largefiles, evolve, phases etc.

Kallithea is fork of RhodeCode, fully supports Mercurial and Git and is open source: https://kallithea-scm.org.

RhodeCode is open-source too and unfortunately looks like Kallithea is a dead project by now. It didn't have a feature release since 2015, only a few bugfixes.

I read a few articles about a new way to work with hg that appeared in the past few years. They were saying that we don't need to have names on every branch. That actually we don't need to name many things and it works much more smoothly. I wonder what is the opinion of hg users here.

I wanted to respond to this thread in general as someone who runs a team that uses Mercurial for most of our work.

But first, the proposal above, in my view, isn’t core mercurial, which is what most of this discussion is centered around. This is mercurial with evolve + topics, which has differences to what many of you are familiar with.

With evolve + topics, many of the critiques of mercurial go away:

  * Light weight branches for short development
  * Ability to squash / fold - mutability
  * Ability to rebase - mutability
With this class of features, you get the major product differentiator that git offers (light weight branches that are simple for collaboration). Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops.

That is why this proposal is important and stands out from bitbuckets offering. Bitbucket (For now) only offers first class evolve support (in beta).

With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”. Topics were very much a game changer for us when we started using them about a year ago. We had previously used bookmarks for collaboration and that situation wasn’t really viable.

Like most people reading this here, our development team targets mostly web development. Most of our dev lives in one repo and generally we target a deploy per day, or multiple per day. We aren’t “continuous delivery”, but we are “effectively” “continuous delivery”.

We have a straight forward workflow. We have a Topic per Jira ticket. That Topic gets cut from the head of the branch “default”. Developers work in these "feature branch" through the features lifecycle, sometimes these are big things (multiple week - big changes) and sometimes small things (hours or days worth of work). Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own.

So with the above as a brief overview of our process and workflow, I wanted to also talk about some of the pain points that mercurial has. Some of these aren’t necessarily caused by mercurial directly, and some aren’t even addressable (ie, if we were to switch to git, we’d have the same problems, or similar)

Pain Points:

  * Tooling kind of sucks. The biggest argument now to use git is less git itself, and more that you are buying into an ecosystem. As an example, we use Buildkite for our CI. Getting this started required some hacking to make it work. Buildkite doesn’t “just work” with HG. That’s generally the tooling story. We can make some stuff work, but most stuff doesn’t “just work”.
  * Merges can occasionally still be painful in a collaborative environment when multiple devs are touching the same files and the same line numbers. I think this is an unsolved problem and probably will remain so until the universe cools to absolute zero.
  * Evolve is great and I use it all the time, but some of developers here complain that it isn’t as well documented as other pieces of mercurial.

  * In my view, the UI is simpler. Our team is comprised of individuals of varying degrees of technical sophistication. For examples, our designers are not software engineers and don’t really need to understand what a DAG is. But they do need to commit directly to our repository, create topics without asking others, and really only ask for help when they did something wrong / got themselves in trouble
  * TortoiseHG. This is a great tool, and most people can get benefit from it. It has some support for topics.
  * All commits are kept for all time. Not everyone finds this valuable. I find this extremely valuable. Evolve handles the mutability question by “hiding” old commits and basically creating new ones.
  * Hg log, which was mentioned before as a burden, in my view is a huge benefit and feature. Most hg commands take a revset.

Your comment is criminally low. Every other comment is 'Git vs. Mercurial' and speculation as to why git has "won". Their not useless, but they are uninteresting technically. So, as a git aficionado, I thank you for a detailed analysis of Mercurial and this proposal.

Personally, I've only used Mercurial to check out some projects that use it exclusively (i.e. (previously) Python and Firefox) and to create a toy repo of no significance (to learn its CLI interface).

Just to highlight a couple things from your comment:

> Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops.

By far the most annoying thing about going from git to mercurial is the overloaded concept of a 'branch'. I couldn't care less about the continued existence of my one-off, topic branch. TBH, I prefer the git concept of the reference pointer being culled in the process. The (git) branch's existence continues on only in the merge commit message. Although this assumes 1) an actual merge was committed (not rebased), 2) the merge wasn't fast-forwarded (--no-ff), and 3) the default merge message format was used.

> With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”.

> Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own.

We use Github. IMO, Github made a HUGE mistake when they added the options to Rebase and Squash in-lieu of the only sane option, Merge. I suspect that a lot of users wanted these options because Github (still) refuses to drop the --no-ff from their Merge strategy. I prefer --no-ff, but I do agree that it does make for an ugly log graph; Unlike most people, I couldn't care less about pretty graphs.) Rebase and Squash shouldn't be considered "Merge" strategies. They're for cleanliness, but only prior to sharing changes. Having them in Github has made the process of figuring out what has (and hasn't) been merged just absolutely atrocious. I'll leave it at that, but needless to say my arguments haven't convinced my peers' desire for pretty graphs.

As far as other user comments, I think the most egregious suggestion has been (paraphrasing):

> Mercurial has (had) better documentation.

Which I think is patently false. Git' manpages are (and always have been) fantastic. git-scm.com has been around for as long as I can remember. If you really want to do so, you can get yourself deep into the git's technical documentation which will teach you everything about the file formats and algorithms that are being used. All of this documentation has been around since git maintenance was handed over to Junio Hamano (circa May, 2005); Long before it's popularity explosion.

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

I've also been around long enough

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://news.ycombinator.com/item?id=6713742

You missed the point of the parent and the grandparent, which both discuss why mercurial being better does not matter.

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.

That comparisong is not fair, but anyway, no need for new languages today, we should improve the existing ones. See UncleBob's opinion on these: http://blog.cleancoder.com/uncle-bob/2015/08/06/LetTheMagicD...

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.

I think other languages have much more to offer over C so that it's worth it. Same for Git over SVN. Hg over Git? Not worth it IMHO.

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.

    git reset --hard
Also people seem to have broken their Hg repositories, too: https://news.ycombinator.com/item?id=18030559

Pity that this doesn't exist for Mercurial then.


I think the other way; git doesn't have much to offer over Hg, so we should all be using Hg.

We are mostly using Git right now though.

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

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

Do you really want a dev environment where there is only one way of doing things?

God, yes!

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 might be right on one hand, but do you think Git is "stagnating"? I don't think 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.

Again, the difference in that case is that llvm is probably an order of magnitude better than gcc. Mercurial is not.

llvm is not an order of magnitude better than gcc as a compiler.

It has a completely different open-source license and that's probably the reason why people bothered.

Hg and Git are both GPLv2.

I don't believe that argument is relevant to the discussion.

As long as that way is one of the best - sure why not?

Because it's impossible to be "one of the best" for all usecases.

It's definitely hard, but why should it be impossible? I don't see the fundamental difference between Git and Hg.

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.

Hg actually cared about the user interface. Git didn't.

Would you hold the stance of only one way to do things if that one way turned out to be hg instead of git?

Yes. I wouldn't if it was bzr though.

Yes, of course! See my comment above.

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"

Yep. Thanks for quoting that.

So jump on Hg, and get everyone to do so. Problem solved.

Actually I would be fine with that, if it would be viable. Unfortunately, it is not.

I don't see it being any more or less viable than getting everyone on Git.

Off-topic, but I think GitLab has incredible good (fast) marketing. If there's any inconvenience their CEO and his minions are there like in a second.

Are there specific tools for that?

Glad to hear this. I hope one day I can go back to Mercurial without the fear of being singled out.

Who other than FB albeit customized is using Mercurial in prod?

JaneStreet I believe.

Nginx: hg.nginx.org/nginx.org



Nice to see someone finally do this. I love the Gitlab team.

as i read it they're not doing it

Oh the irony, phabricator has had mercurial support since day one almost.

I evaluated phabricator today for Hg hosting at $DAYJOB. Issues in Maniphest aren't "attached" to a Diffusion repo, so you can't use it as a Gitea/Github-style one-repo-one-project system; it's one-phabricator-one-project-multi-repos. Spaces help a little bit but not really.

Dealbreaker for us - we'd rather retrain staff on hg->git (and lose the amazing TortoiseHg).

I'm unfamiliar with phabricator's history. What makes it ironic?

Did it have both out the gate and meet criticism?

Phabricator doesn't support fork model.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact