10 ms·

Mercurial, 20 years and counting: how are we still alive and kicking? [video]

213 points by ibobev 6mo ago

jmole 6mo ago
hg (fig) was definitely my favorite frontend for source control at google.
srean 6mo ago
I am glad the Hginit is back https://hginit.github.io/index.html https://hginit.github.io/index.html Not sure why it has to disappear in the first place. What's going on with hginit.com now ?
macro-b 6mo ago
At my previous big tech employer we used to have a mercurial layer on top of our legacy version control system. I loved it, much simpler and more clear than the typical workflows I have to deal with in git. I get it that with git you have more power, but do really most teams need that?
- KwanEsq 6mo ago
  Do you actually even have more power with git?
  - g-b-r 6mo ago
    No, it's the opposite
  - 12_throw_away 6mo ago
    Unless git has some hidden way to do changeset evolution (maybe with jujutsu on top?) then no - I'm pretty sure git is strictly less powerful than hg these days.
- juvoly 6mo ago
  Mercurial wasn't as simple as Subversion. But with hg I still felt like understanding 80% of what the tool had to offer and actually being able to mold the timeline the way I wanted. Git has so many gotchas, bells and whistles that whenever I'm doing something out of the ordinary I'm wondering if there isn't an easier / canonical / smarter way I should be doing it.
  - mark_undoio 6mo ago
    There was a quote somewhere about Mercurial having a mental model small enough you can fit in your head - and that was the big win for me. It was also fast and had very clean, easy to contribute to code. I remember submitting a patch and getting a bit of Python education from Matt, which was very useful. Git is fine but it's inconsistent enough in the interface department, even after all this time, that I still get regularly frustrated. On the other hand, you can't just break a workflow that already exists and I very much appreciate it scales to work far beyond mine. I do like that the git people are doing the difficult work of improving the UI over time - it's hard to change the engines while the plane is flying!
    - codesnik 6mo ago
      git's mental model is very, very small, if you care to learn it. Then all the commands and their "inconsistencies" start to make sense - they operate on the model almost without any magic, and not on whatever is user's intent (it can vary a lot)
  - tasuki 6mo ago
    > Mercurial wasn't as simple as Subversion. What? Subversion is by far the most complex versioning software I've ever used. > Git has so many gotchas, bells and whistles The Git UI leaves a little to be desired. But inside, Git is basically just blobs, trees, commits, and refs. It'd be hard (or impossible?) to find a conceptually simpler versioning system.
    - juvoly 6mo ago
      You're right about SVN's guts vs Git. I should have been clearer that I was referring to the client cli only.
- Espressosaurus 6mo ago
  Git doesn't give you more power, it just makes their internals your problem.
5aasj3t 6mo ago
[flagged]
- throwaway894345 6mo ago
  Honestly hg shot themselves in the foot by not releasing any stable API and making developers use their CLI interface. Between that and the performance and dynamic typing issues of Python, it was almost sure to lose the race to Git.
  - Pay08 6mo ago
    Git doesn't have any sort of API either, libgit2 is unofficial.
    - throwaway894345 6mo ago
      Git's filesystem layout has always been stable and Git encouraged developers to target it. Mercurial strongly cautioned developers away from its filesystem or source code APIs and told them to subprocess out to the CLI. To be clear, I dislike Git, but it was _designed_ with developers in mind (which isn't to say that it has a nice API, only that the Git people intended for Git to be extended). I prefer Mercurial's concepts and interface, but Mercurial was somewhere between indifferent and hostile toward developers.
      - deleted 6mo ago
        [deleted]
zabzonk 6mo ago
I loved Mercurial - still do I guess as I just installed it on the Linux Mint VM I keep around for messing with Linux. The thing I really liked about it was TortoiseHg, which provides integration between Mercurial and Windows Explorer. There is a similar TortoiseGit but, at least back when I was doing serious development, it had quite a few problems.
- Pay08 6mo ago
  FWIW, as a recent user of TortoiseGit, it seems pretty decent nowadays.
  - zabzonk 6mo ago
    That's what I expected - I was sure the Tortoise guys would get it right eventually.
PathOfEclipse 6mo ago
Almost 20 years ago I helped our company choose between Git and Mercurial as the replacement for Subversion. Unfortunately, I helped them make the wrong choice, Mercurial. I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and performance needed. But I guess I couldn't read the future in terms of which one would win out!
- woadwarrior01 6mo ago
  I'd made the exact same choice around the same time at the company where I was working. Last I heard, they're still using it. My rationale was that Mercurial was a lot safer and user-friendly compared to git. Needless to say, git has improved by leaps and bounds since then.
- avarun 6mo ago
  Around 20 years ago Facebook made the same choice, so you're in good company in terms of technically sophisticated shops.
  - loeg 6mo ago
    Facebook has been using their own in-house Sapling/Eden for years and years now. I'm not sure how much similarity remains with open source Mercurial.
    - zeroonetwothree 6mo ago
      You can use all the normal hg commands at Meta. It’s a regular mercurial repo from the standpoint of a user
      - loeg 6mo ago
        Yeah, but people using open source mercurial aren't in the same boat. It's a different codebase.
idank 6mo ago
Anyone know what Matt Mackall is up to these days? He started Mercurial and got people involved early on with a lot of enthusiasm, you could tell he cared about what he created and the people who joined him ("hg crew"). I learned a lot from him on how to think like an engineer and saw him manage different personalities in the project in a kind and sincere way (I think this was around ~2010).
- interroboink 6mo ago
  FYI: Matt Mackall is now Olivia Mackall [1], so that can make searching for things harder. Looks like they work at Valve, now? Agreed that they were a really stabilizing and healthy personality in the project, and made a lot of good early decisions, which Mercurial has continually benefited from. Eg: the commitment to backwards-compatibility [2]. [1] https://repo.mercurial-scm.org/hg-stable/rev/d4ba4d51f85f https://repo.mercurial-scm.org/hg-stable/rev/d4ba4d51f85f [2] https://wiki.mercurial-scm.org/CompatibilityRules https://wiki.mercurial-scm.org/CompatibilityRules
  - sunshowers 6mo ago
    Olivia uses she/her, and I believe she is now retired :) I owe her and the Mercurial community a great debt. The community taught me how to think like an engineer building infrastructure and the importance of backwards compatibility, something I've tried to carry forward in tools like cargo-nextest.
- tonfa 6mo ago
  +1 I learned so much about software engineering (Software design, network protocol incl how to handle backward compat in sane ways, ...) thanks to the mercurial community.
chiph 6mo ago
I just installed it on a Raspberry Pi (with an otherwise too-small-for-any-other purpose SSD) for use at home. I wanted something with low power consumption, and I didn't want to have a single point of failure by running it in a container alongside everything else. The only hiccup was forgetting that when pushing via the SSH connection, it will have paths relative to the home directory of my hg user.
ssttoo 6mo ago
IIRC Facebook switched to HG from SVN in the 2010s, one (main?) motivator being that the single repo was getting too big and svn’s only way was to start splitting it up. Which was against the philosophy of openness of the single repo. No idea what’s Meta doing now.
- Shish2k 6mo ago
  Last I checked (2 years ago) Meta was using Sapling, a very heavily customised open source Mercurial frontend with proprietary backend. FWIW the Sapling frontend can also be connected to a Git backend, and I've been using that for all my open source projects to get the best of Mercurial's user experience niceness while collaborating via GitHub <3
  - loeg 6mo ago
    Still Sapling + Eden to make local work on a sparse checkout viable.
rileymat2 6mo ago
In my time with it, about ~20 years ago, it had a lot of nice features for instance hg came with a web server/interface out of the box.
- ciupicri 6mo ago
  I liked too. It was `hg serve` [1]. Instant web interface and an easy way to share the repository with other people (assuming your computer was accessible from the LAN or Internet). [1]: https://mercurial-scm.org/help/commands/serve https://mercurial-scm.org/help/commands/serve
TLLtchvL8KZ 6mo ago
I haven't used hg in years now, bitbucket discontinuing support is what killed it for me and I had no interest in self hosting. My git usage is very basic, my gitconfig has been pretty much untouched for years but on those occasions where I get stuck or hit something I end up searching and usually get through a bunch of posts/comments/sites and wish I was using hg.
DavidCanHelp 6mo ago
Related: https://github.com/cloudstreet-dev/What-we-lost-when-Git-won https://github.com/cloudstreet-dev/What-we-lost-when-Git-won
Zopieux 6mo ago
I sincerely hope jj gets the recognition it deserves in coming years.
t43562 6mo ago
Mercurial was safer and better. I still use it and it's still safer. The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though. I'm probably dumb but I can't work it out and hence the overall tool is that much less useful. It needs a github-like website and Heptapod would be great if I could use it - I've set up a project, been unable to do anything and then had it all closed down. OTOH self-hosting is a lot more feasible nowadays with today's fibre connections.
- ciupicri 6mo ago
  I hated so much how Mercurial dealt with short-lived branches, that after seeing how Git did it, I've never looked back. I also remember how some people told me to use the quilt or something extension to manage patches, but it was too complicated for me.
  - seany 6mo ago
    It make a lot of sense if you think of repo history as properly immutable, and dispose of the notion that brach is a first class object in the git sense. Bookmakers just pin a checkin hash to a name, and you can have many heads in an hg branch.
  - irishcoffee 6mo ago
    What does short lives branches even mean? Make a branch, close it, or merge it.
    - interroboink 6mo ago
      Short-lived branches are likely referring to "bookmarks" in Mercurial. Or they could also just be un-named anonymous heads. These are different from what is exposed by the "hg branch" command. Mercurial's "branch" was generally intended for long-lived things. Think the "stable branch" or a "version X" support branch for a project. The branch name is baked into the commits that use it. You can hide them from the UI with "--close-branch", but they will still exist forever in the commit history. This is both a good thing and a bad thing, depending on your desires. This is different from Git's "branch" which is basically just a pointer to a commit. It is not part of commit history, it is just a convenience for the developer. Later, Mercurial added "bookmarks" which are similar.
QuadrupleA 6mo ago
[dead]
forrestthewoods 6mo ago
Mercurial is just better than Git. But GitHub won and so Git won.
mnahkies 6mo ago
My first full time job after university was using hg, and particularly https://tortoisehg.bitbucket.io/ https://tortoisehg.bitbucket.io/ made it really pleasant. Prior and post that I'd always used git but I'll always have a bit of a soft spot for mercurial, especially as our forge usage at the time predated strict guardrails and controls - we did code review, but it was your responsibility to tag the appropriate people and wait for them to respond, if you felt it was necessary to merge prior to that you could - but better be ready to defend that decision.
jgalt212 6mo ago
Our shop uses Mercurial, and I hop we never move to Git, but I do see us eventually moving to whatever is next.
BeetleB 6mo ago
I always preferred Mercurial to Git, but now that Jujutsu is out there, I think Mercurial's demise is all but guaranteed. If there were a reliable way to use Mercurial on a Git repository, it could live. But why bother when one can use Jujutsu?
- kccqzy 6mo ago
  Jujutsu took the best parts about mercurial and enabled these to be used with git and git forges. Once I had gotten used to jujutsu I didn’t really miss mercurial.
holoduke 6mo ago
Just a bit off topic. But is anyone still using git or whatever versioning in the traditional way? I hardly see myself using the git command these days. Everything I handled by Claude. From pulling to pushing to solve merge conflicts and more. In a way it doesn't matter anymore whether it's git or something else.
qa3-tech 6mo ago
Glad it is still around. hg was the better experience as it had fewer command surface. But slower, and sometimes you need the extra detail commands to analyze the history.
kgk9000 6mo ago
Git likely won because of GitHub; I abandoned Mercurial quite early when it was clear that it had lost. It was good, but I cannot imagine using it today.
jedberg 6mo ago
We used Mercurial at reddit. We switched to it shortly after switching to Python as our main language, figuring it would be easier to use the one written in Python. We used Mercurial until the day we went open source. We actually preferred it, but we knew at that point that "everyone" used Git, and we would never be seen as serious or get user contributions unless we switched. That was back in 2008. [0] We actually self hosted a ticketing system[1] and our own git repo, but since the system we used didn't have pull requests, we had to use the old school method of sending us a patch via mailing list using the git-send-email command, the same way the linux kernel did it. The best part of this is that we had a launch party for open sourcing in San Francisco. The date of the party was chosen a few months in advance, because it takes that long to plan something in physical meat space. This was basically the first time reddit ever had a hard deadline to get something done. I was primarily responsible for setting up the ticketing system and code repo, and at the same time, we were switching our actual servers to pull from our public code repo for deployment, for true transparency (and I had to set all that up too). I actually had to do the final setup to make everything public sitting at the bar at the venue with my laptop about five minutes before we opened the doors. At the time, I had about a week of experience with git! And here I was, operating what was expected to be a very popular open repo that anyone could clone from. Good times. [0] https://web.archive.org/web/20080619043654/http://blog.reddit.com/2008/06/reddit-goes-open-source.html https://web.archive.org/web/20080619043654/http://blog.reddi... [1] https://web.archive.org/web/20080622134154/http://code.reddit.com/wiki/PatchSubmit https://web.archive.org/web/20080622134154/http://code.reddi...
bombcar 6mo ago
I still wish bzr had had a better showing.
throwatdem12311 6mo ago
How is the rust rewrite going?
SonnyTark 6mo ago
I hung on to hg all the way until bitbucket forced migration to git. I still dislike git, but I dislike perforce much more. I guess I just wanted to say I hate perforce lol
7e 6mo ago
Mercurial is so, so slow. It is painful to use.
irishcoffee 6mo ago
I should write a whole article about this. Hg is a superior tool compared to git. It logically just clicks, for everyone. Changesets, branching, merging, tagging, it all just works. Git is this arcane blob of whatever-you-call-it where rewriting/erasing history is not only allowed, its encouraged. That is insane to me. Git is a fine tool, it is in every possible way inferior to hg.
- pitkali 5mo ago
  I never got the idea from git itself that changing history is encouraged. What makes you say otherwise?
  - irishcoffee 5mo ago
    git rebase Is a widely accepted command as a daily part of a development workflow. This command rewrites history.
    - pitkali 5mo ago
      Its mere availability is not "encouragement."
eeeficus 6mo ago
Unpopular opinion: Git is better than Mercurial and people just make a big fuss when you refuse to play with their toys!
garganzol 5mo ago
We support Mercurial project financially and we use it everyday. While I use Git for hobby projects, it does not cut it in terms of ease of use. Some newer SCM systems like jj look promising, but absence of tools like TortoiseHg undermines their possible adoption.

213 points by ibobev 6mo ago

jmole 6mo ago

hg (fig) was definitely my favorite frontend for source control at google.

srean 6mo ago

I am glad the Hginit is back https://hginit.github.io/index.html https://hginit.github.io/index.html Not sure why it has to disappear in the first place. What's going on with hginit.com now ?

macro-b 6mo ago

At my previous big tech employer we used to have a mercurial layer on top of our legacy version control system. I loved it, much simpler and more clear than the typical workflows I have to deal with in git. I get it that with git you have more power, but do really most teams need that?

KwanEsq 6mo ago
Do you actually even have more power with git?
- g-b-r 6mo ago
  No, it's the opposite
- 12_throw_away 6mo ago
  Unless git has some hidden way to do changeset evolution (maybe with jujutsu on top?) then no - I'm pretty sure git is strictly less powerful than hg these days.
juvoly 6mo ago
Mercurial wasn't as simple as Subversion. But with hg I still felt like understanding 80% of what the tool had to offer and actually being able to mold the timeline the way I wanted. Git has so many gotchas, bells and whistles that whenever I'm doing something out of the ordinary I'm wondering if there isn't an easier / canonical / smarter way I should be doing it.
- mark_undoio 6mo ago
  There was a quote somewhere about Mercurial having a mental model small enough you can fit in your head - and that was the big win for me. It was also fast and had very clean, easy to contribute to code. I remember submitting a patch and getting a bit of Python education from Matt, which was very useful. Git is fine but it's inconsistent enough in the interface department, even after all this time, that I still get regularly frustrated. On the other hand, you can't just break a workflow that already exists and I very much appreciate it scales to work far beyond mine. I do like that the git people are doing the difficult work of improving the UI over time - it's hard to change the engines while the plane is flying!
  - codesnik 6mo ago
    git's mental model is very, very small, if you care to learn it. Then all the commands and their "inconsistencies" start to make sense - they operate on the model almost without any magic, and not on whatever is user's intent (it can vary a lot)
- tasuki 6mo ago
  > Mercurial wasn't as simple as Subversion. What? Subversion is by far the most complex versioning software I've ever used. > Git has so many gotchas, bells and whistles The Git UI leaves a little to be desired. But inside, Git is basically just blobs, trees, commits, and refs. It'd be hard (or impossible?) to find a conceptually simpler versioning system.
  - juvoly 6mo ago
    You're right about SVN's guts vs Git. I should have been clearer that I was referring to the client cli only.
Espressosaurus 6mo ago
Git doesn't give you more power, it just makes their internals your problem.

5aasj3t 6mo ago

[flagged]

throwaway894345 6mo ago
Honestly hg shot themselves in the foot by not releasing any stable API and making developers use their CLI interface. Between that and the performance and dynamic typing issues of Python, it was almost sure to lose the race to Git.
- Pay08 6mo ago
  Git doesn't have any sort of API either, libgit2 is unofficial.
  - throwaway894345 6mo ago
    Git's filesystem layout has always been stable and Git encouraged developers to target it. Mercurial strongly cautioned developers away from its filesystem or source code APIs and told them to subprocess out to the CLI. To be clear, I dislike Git, but it was _designed_ with developers in mind (which isn't to say that it has a nice API, only that the Git people intended for Git to be extended). I prefer Mercurial's concepts and interface, but Mercurial was somewhere between indifferent and hostile toward developers.
    - deleted 6mo ago
      [deleted]

zabzonk 6mo ago

I loved Mercurial - still do I guess as I just installed it on the Linux Mint VM I keep around for messing with Linux. The thing I really liked about it was TortoiseHg, which provides integration between Mercurial and Windows Explorer. There is a similar TortoiseGit but, at least back when I was doing serious development, it had quite a few problems.

Pay08 6mo ago
FWIW, as a recent user of TortoiseGit, it seems pretty decent nowadays.
- zabzonk 6mo ago
  That's what I expected - I was sure the Tortoise guys would get it right eventually.

PathOfEclipse 6mo ago

Almost 20 years ago I helped our company choose between Git and Mercurial as the replacement for Subversion. Unfortunately, I helped them make the wrong choice, Mercurial. I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and performance needed. But I guess I couldn't read the future in terms of which one would win out!

woadwarrior01 6mo ago
I'd made the exact same choice around the same time at the company where I was working. Last I heard, they're still using it. My rationale was that Mercurial was a lot safer and user-friendly compared to git. Needless to say, git has improved by leaps and bounds since then.
avarun 6mo ago
Around 20 years ago Facebook made the same choice, so you're in good company in terms of technically sophisticated shops.
- loeg 6mo ago
  Facebook has been using their own in-house Sapling/Eden for years and years now. I'm not sure how much similarity remains with open source Mercurial.
  - zeroonetwothree 6mo ago
    You can use all the normal hg commands at Meta. It’s a regular mercurial repo from the standpoint of a user
    - loeg 6mo ago
      Yeah, but people using open source mercurial aren't in the same boat. It's a different codebase.

idank 6mo ago

Anyone know what Matt Mackall is up to these days? He started Mercurial and got people involved early on with a lot of enthusiasm, you could tell he cared about what he created and the people who joined him ("hg crew"). I learned a lot from him on how to think like an engineer and saw him manage different personalities in the project in a kind and sincere way (I think this was around ~2010).

interroboink 6mo ago
FYI: Matt Mackall is now Olivia Mackall [1], so that can make searching for things harder. Looks like they work at Valve, now? Agreed that they were a really stabilizing and healthy personality in the project, and made a lot of good early decisions, which Mercurial has continually benefited from. Eg: the commitment to backwards-compatibility [2]. [1] https://repo.mercurial-scm.org/hg-stable/rev/d4ba4d51f85f https://repo.mercurial-scm.org/hg-stable/rev/d4ba4d51f85f [2] https://wiki.mercurial-scm.org/CompatibilityRules https://wiki.mercurial-scm.org/CompatibilityRules
- sunshowers 6mo ago
  Olivia uses she/her, and I believe she is now retired :) I owe her and the Mercurial community a great debt. The community taught me how to think like an engineer building infrastructure and the importance of backwards compatibility, something I've tried to carry forward in tools like cargo-nextest.
tonfa 6mo ago
+1 I learned so much about software engineering (Software design, network protocol incl how to handle backward compat in sane ways, ...) thanks to the mercurial community.

chiph 6mo ago

I just installed it on a Raspberry Pi (with an otherwise too-small-for-any-other purpose SSD) for use at home. I wanted something with low power consumption, and I didn't want to have a single point of failure by running it in a container alongside everything else. The only hiccup was forgetting that when pushing via the SSH connection, it will have paths relative to the home directory of my hg user.

ssttoo 6mo ago

IIRC Facebook switched to HG from SVN in the 2010s, one (main?) motivator being that the single repo was getting too big and svn’s only way was to start splitting it up. Which was against the philosophy of openness of the single repo. No idea what’s Meta doing now.

Shish2k 6mo ago
Last I checked (2 years ago) Meta was using Sapling, a very heavily customised open source Mercurial frontend with proprietary backend. FWIW the Sapling frontend can also be connected to a Git backend, and I've been using that for all my open source projects to get the best of Mercurial's user experience niceness while collaborating via GitHub <3
- loeg 6mo ago
  Still Sapling + Eden to make local work on a sparse checkout viable.

rileymat2 6mo ago

In my time with it, about ~20 years ago, it had a lot of nice features for instance hg came with a web server/interface out of the box.

ciupicri 6mo ago
I liked too. It was `hg serve` [1]. Instant web interface and an easy way to share the repository with other people (assuming your computer was accessible from the LAN or Internet). [1]: https://mercurial-scm.org/help/commands/serve https://mercurial-scm.org/help/commands/serve

TLLtchvL8KZ 6mo ago

I haven't used hg in years now, bitbucket discontinuing support is what killed it for me and I had no interest in self hosting. My git usage is very basic, my gitconfig has been pretty much untouched for years but on those occasions where I get stuck or hit something I end up searching and usually get through a bunch of posts/comments/sites and wish I was using hg.

DavidCanHelp 6mo ago

Related: https://github.com/cloudstreet-dev/What-we-lost-when-Git-won https://github.com/cloudstreet-dev/What-we-lost-when-Git-won

Zopieux 6mo ago

I sincerely hope jj gets the recognition it deserves in coming years.

t43562 6mo ago

Mercurial was safer and better. I still use it and it's still safer. The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though. I'm probably dumb but I can't work it out and hence the overall tool is that much less useful. It needs a github-like website and Heptapod would be great if I could use it - I've set up a project, been unable to do anything and then had it all closed down. OTOH self-hosting is a lot more feasible nowadays with today's fibre connections.

ciupicri 6mo ago
I hated so much how Mercurial dealt with short-lived branches, that after seeing how Git did it, I've never looked back. I also remember how some people told me to use the quilt or something extension to manage patches, but it was too complicated for me.
- seany 6mo ago
  It make a lot of sense if you think of repo history as properly immutable, and dispose of the notion that brach is a first class object in the git sense. Bookmakers just pin a checkin hash to a name, and you can have many heads in an hg branch.
- irishcoffee 6mo ago
  What does short lives branches even mean? Make a branch, close it, or merge it.
  - interroboink 6mo ago
    Short-lived branches are likely referring to "bookmarks" in Mercurial. Or they could also just be un-named anonymous heads. These are different from what is exposed by the "hg branch" command. Mercurial's "branch" was generally intended for long-lived things. Think the "stable branch" or a "version X" support branch for a project. The branch name is baked into the commits that use it. You can hide them from the UI with "--close-branch", but they will still exist forever in the commit history. This is both a good thing and a bad thing, depending on your desires. This is different from Git's "branch" which is basically just a pointer to a commit. It is not part of commit history, it is just a convenience for the developer. Later, Mercurial added "bookmarks" which are similar.

QuadrupleA 6mo ago

[dead]

forrestthewoods 6mo ago

Mercurial is just better than Git. But GitHub won and so Git won.

mnahkies 6mo ago

My first full time job after university was using hg, and particularly https://tortoisehg.bitbucket.io/ https://tortoisehg.bitbucket.io/ made it really pleasant. Prior and post that I'd always used git but I'll always have a bit of a soft spot for mercurial, especially as our forge usage at the time predated strict guardrails and controls - we did code review, but it was your responsibility to tag the appropriate people and wait for them to respond, if you felt it was necessary to merge prior to that you could - but better be ready to defend that decision.

jgalt212 6mo ago

Our shop uses Mercurial, and I hop we never move to Git, but I do see us eventually moving to whatever is next.

BeetleB 6mo ago

I always preferred Mercurial to Git, but now that Jujutsu is out there, I think Mercurial's demise is all but guaranteed. If there were a reliable way to use Mercurial on a Git repository, it could live. But why bother when one can use Jujutsu?

kccqzy 6mo ago
Jujutsu took the best parts about mercurial and enabled these to be used with git and git forges. Once I had gotten used to jujutsu I didn’t really miss mercurial.

holoduke 6mo ago

Just a bit off topic. But is anyone still using git or whatever versioning in the traditional way? I hardly see myself using the git command these days. Everything I handled by Claude. From pulling to pushing to solve merge conflicts and more. In a way it doesn't matter anymore whether it's git or something else.

qa3-tech 6mo ago

Glad it is still around. hg was the better experience as it had fewer command surface. But slower, and sometimes you need the extra detail commands to analyze the history.

kgk9000 6mo ago

Git likely won because of GitHub; I abandoned Mercurial quite early when it was clear that it had lost. It was good, but I cannot imagine using it today.

jedberg 6mo ago

We used Mercurial at reddit. We switched to it shortly after switching to Python as our main language, figuring it would be easier to use the one written in Python. We used Mercurial until the day we went open source. We actually preferred it, but we knew at that point that "everyone" used Git, and we would never be seen as serious or get user contributions unless we switched. That was back in 2008. [0] We actually self hosted a ticketing system[1] and our own git repo, but since the system we used didn't have pull requests, we had to use the old school method of sending us a patch via mailing list using the git-send-email command, the same way the linux kernel did it. The best part of this is that we had a launch party for open sourcing in San Francisco. The date of the party was chosen a few months in advance, because it takes that long to plan something in physical meat space. This was basically the first time reddit ever had a hard deadline to get something done. I was primarily responsible for setting up the ticketing system and code repo, and at the same time, we were switching our actual servers to pull from our public code repo for deployment, for true transparency (and I had to set all that up too). I actually had to do the final setup to make everything public sitting at the bar at the venue with my laptop about five minutes before we opened the doors. At the time, I had about a week of experience with git! And here I was, operating what was expected to be a very popular open repo that anyone could clone from. Good times. [0] https://web.archive.org/web/20080619043654/http://blog.reddit.com/2008/06/reddit-goes-open-source.html https://web.archive.org/web/20080619043654/http://blog.reddi... [1] https://web.archive.org/web/20080622134154/http://code.reddit.com/wiki/PatchSubmit https://web.archive.org/web/20080622134154/http://code.reddi...

bombcar 6mo ago

I still wish bzr had had a better showing.

throwatdem12311 6mo ago

How is the rust rewrite going?

SonnyTark 6mo ago

I hung on to hg all the way until bitbucket forced migration to git. I still dislike git, but I dislike perforce much more. I guess I just wanted to say I hate perforce lol

7e 6mo ago

Mercurial is so, so slow. It is painful to use.

irishcoffee 6mo ago

I should write a whole article about this. Hg is a superior tool compared to git. It logically just clicks, for everyone. Changesets, branching, merging, tagging, it all just works. Git is this arcane blob of whatever-you-call-it where rewriting/erasing history is not only allowed, its encouraged. That is insane to me. Git is a fine tool, it is in every possible way inferior to hg.

pitkali 5mo ago
I never got the idea from git itself that changing history is encouraged. What makes you say otherwise?
- irishcoffee 5mo ago
  git rebase Is a widely accepted command as a daily part of a development workflow. This command rewrites history.
  - pitkali 5mo ago
    Its mere availability is not "encouragement."

eeeficus 6mo ago

Unpopular opinion: Git is better than Mercurial and people just make a big fuss when you refuse to play with their toys!

garganzol 5mo ago

We support Mercurial project financially and we use it everyday. While I use Git for hobby projects, it does not cut it in terms of ease of use. Some newer SCM systems like jj look promising, but absence of tools like TortoiseHg undermines their possible adoption.