6 ms·

I totally agree about Mercurial's superior ease of use and simpler mental model. However, it feels quite abandoned. I don't know what caused it though. It's a p

by sedatk 3y ago

I totally agree about Mercurial's superior ease of use and simpler mental model. However, it feels quite abandoned. I don't know what caused it though. It's a perfectly viable alternative to Git in my opinion.

madeofpalk 3y ago
I tried contributing to firefox, but figuring out mercurial was a huge discourger.
- fhd2 3y ago
  I never understood how people can happily figure out a gigantic, complicated code base like Firefox and are taken aback by learning a little bit about some tool. In your case, was it a thing where working with an unfamiliar tool was simply demotivating? Cause I think if you can write a Firefox patch, you should be able to learn Mercurial during breakfast.
  - bdd8f1df777b 3y ago
    I could resonate with him/her if I were not familiar with Mercurial. Because he/she is aiming to fix or improve Firefox, figuring out a gigantic, complicated code base of Firefox is directly towards his/her end goal. Meanwhile, figuring out hg feels a waste of time.
  - 4death4 3y ago
    Is not wanting to do extra work really that hard to understand?
  - madeofpalk 3y ago
    I didn't need to figure out a gigantic, complicated codebase. I only needed to figure out devtools frontend which is a significantly smaller portion of it and relatively self-contained.
  - PH95VuimJjqBqy 3y ago
    For the same reason I get frustrated when I go to solve problem A, run into problem B then while trying to solve problem B I run into problem C. Soon enough you have 15 problems you want solved but you find yourself having to unwind a stack 1 by 1 until you _finally_ get to a point where you can actually solve the original problem. People probably view dealing with the FF codebase as part of Problem A, dealing with mercurial is Problem B, which is must less appreciated.
- sedatk 3y ago
  Which problems did you encounter while figuring out Mercurial?
  - radarsat1 3y ago
    Speaking for myself, coming from git, I found the branching model of Mercurial hard to understand. Then it turns out that instead of branches I should have been using "bookmarks"? But which to use when? I tried to work on a Mercurial-based project (not firefox) but eventually gave up and just used git to track my changes and then prepare, very carefully, specific big merged commits to contribute back. It was easier, because I could never figure out how to clean up properly if I made a mistake -- so this way, I could just wipe the local copy and start over instead. But it was annoying, and I was glad to stop using it. Completely bewildered by every thread about mercurial full of people proclaiming its advantages and "simpler mental model". Simpler than a DAG with pointers? Sure. If I remember correctly you even needed to install some kind of external plugin just to do simple rebasing / branch cleanup. Now's the part where you tell me I'm doing it wrong, shouldn't be rebasing etc etc, but I'm just saying, it didn't work for me; and the constant claims that it's somehow objectively "better" but misunderstood get really boring.
    - adhesive_wombat 3y ago
      The thing about git is that while it does leak the implementation a bit and some of the CLI commands show their history of its emergency cobbling-together, it supports many many workflows equally well. At the expense of not having one completely gleamingly-simple happy path as a first-class citizen. It's a bit like C in that respect, which isn't especially surprising considering the inventor.
    - atq2119 3y ago
      Thank you for putting my own (~10 years ago) experience with Mercurial into words.
    - btreecat 3y ago
      That's one diff between git and Hg. Hg likes to consider the history "sacred" so there's no "cleaning up your commit" via squashing/cherry picking. This is actually superior in most cases. Being able to force rewrite history so easily in git was a design mistake imo.
bdd8f1df777b 3y ago
Not abandoned. Both Facebook and Google internally use Mercurial as one of the version control systems. They will keep the Mercurial project alive.
- godzillabrennus 3y ago
  Explaining in a nutshell why mainframes are still in use and COBOL has market demand.
- progbits 3y ago
  See sibling comment linking to https://github.com/martinvonz/jj https://github.com/martinvonz/jj I expect google to switch to that.
- aseipp 3y ago
  Facebook uses a heavily modified fork of Mercurial which they have (as of last year) released publicly, and now refer to it by a new name, "Sapling" (though the command may still be called 'hg' internally). And Sapling actually stores data using Git's on-disk format, along with an entirely bespoke server-side backend. It is an entirely different project from Mercurial, now.

by sedatk 3y ago

madeofpalk 3y ago

I tried contributing to firefox, but figuring out mercurial was a huge discourger.

fhd2 3y ago
I never understood how people can happily figure out a gigantic, complicated code base like Firefox and are taken aback by learning a little bit about some tool. In your case, was it a thing where working with an unfamiliar tool was simply demotivating? Cause I think if you can write a Firefox patch, you should be able to learn Mercurial during breakfast.
- bdd8f1df777b 3y ago
  I could resonate with him/her if I were not familiar with Mercurial. Because he/she is aiming to fix or improve Firefox, figuring out a gigantic, complicated code base of Firefox is directly towards his/her end goal. Meanwhile, figuring out hg feels a waste of time.
- 4death4 3y ago
  Is not wanting to do extra work really that hard to understand?
- madeofpalk 3y ago
  I didn't need to figure out a gigantic, complicated codebase. I only needed to figure out devtools frontend which is a significantly smaller portion of it and relatively self-contained.
- PH95VuimJjqBqy 3y ago
  For the same reason I get frustrated when I go to solve problem A, run into problem B then while trying to solve problem B I run into problem C. Soon enough you have 15 problems you want solved but you find yourself having to unwind a stack 1 by 1 until you _finally_ get to a point where you can actually solve the original problem. People probably view dealing with the FF codebase as part of Problem A, dealing with mercurial is Problem B, which is must less appreciated.
sedatk 3y ago
Which problems did you encounter while figuring out Mercurial?
- radarsat1 3y ago
  Speaking for myself, coming from git, I found the branching model of Mercurial hard to understand. Then it turns out that instead of branches I should have been using "bookmarks"? But which to use when? I tried to work on a Mercurial-based project (not firefox) but eventually gave up and just used git to track my changes and then prepare, very carefully, specific big merged commits to contribute back. It was easier, because I could never figure out how to clean up properly if I made a mistake -- so this way, I could just wipe the local copy and start over instead. But it was annoying, and I was glad to stop using it. Completely bewildered by every thread about mercurial full of people proclaiming its advantages and "simpler mental model". Simpler than a DAG with pointers? Sure. If I remember correctly you even needed to install some kind of external plugin just to do simple rebasing / branch cleanup. Now's the part where you tell me I'm doing it wrong, shouldn't be rebasing etc etc, but I'm just saying, it didn't work for me; and the constant claims that it's somehow objectively "better" but misunderstood get really boring.
  - adhesive_wombat 3y ago
    The thing about git is that while it does leak the implementation a bit and some of the CLI commands show their history of its emergency cobbling-together, it supports many many workflows equally well. At the expense of not having one completely gleamingly-simple happy path as a first-class citizen. It's a bit like C in that respect, which isn't especially surprising considering the inventor.
  - atq2119 3y ago
    Thank you for putting my own (~10 years ago) experience with Mercurial into words.
  - btreecat 3y ago
    That's one diff between git and Hg. Hg likes to consider the history "sacred" so there's no "cleaning up your commit" via squashing/cherry picking. This is actually superior in most cases. Being able to force rewrite history so easily in git was a design mistake imo.

bdd8f1df777b 3y ago

Not abandoned. Both Facebook and Google internally use Mercurial as one of the version control systems. They will keep the Mercurial project alive.

godzillabrennus 3y ago
Explaining in a nutshell why mainframes are still in use and COBOL has market demand.
progbits 3y ago
See sibling comment linking to https://github.com/martinvonz/jj https://github.com/martinvonz/jj I expect google to switch to that.
aseipp 3y ago
Facebook uses a heavily modified fork of Mercurial which they have (as of last year) released publicly, and now refer to it by a new name, "Sapling" (though the command may still be called 'hg' internally). And Sapling actually stores data using Git's on-disk format, along with an entirely bespoke server-side backend. It is an entirely different project from Mercurial, now.