9 ms·

Sad to see another Mercurial holdout switch to Git. The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used

Sad to see another Mercurial holdout switch to Git. The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used it more but - network effects! - used git because of the projects I was working on. The main thing was that the mental model of Mercurial fit in my head and the CLI was predictable and regular, whilst the tool still scaled to large codebases. I find Git wants me to think about its implementation details and internal terminology at unpredictable moments during use. It still gets the job done but it feels like doing random CAPTCHAs in the midst of my work.

deleted 3y ago
[deleted]
ocharles 3y ago
You might like https://github.com/martinvonz/jj https://github.com/martinvonz/jj, which gives an alternative frontend to Git.
- mark_undoio 3y ago
  Thanks - that looks interesting. It's especially appealing because it seems to add value beyond just being a neater wrapper to the same operations, it looks like it'll enable new ways of working with the tool.
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?
- 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.
pjmlp 3y ago
Yeah pour another glass for Mercurial, it is a shame that git ended up winning, but then again what to expect when it was a child of Linux kernel project.
- bayindirh 3y ago
  Some arguably* technically superior designs end up being obsoleted over time, because the arguably* inferior design ends up being more lined up with how people think and machines work. This is what we're seeing here, IMHO. *: There's nothing "objectively something" in computer science, because it's all is a pile trade-offs to get the desired result.
  - The_Colonel 3y ago
    Well, can you explain why it applies here? Mercurial vs. Git is IMHO a textbook example of "good enough with large user base" beats "subtly superior with smaller user base" over the long term.
    - lovepronmostly 3y ago
      hg was not superior to git at v1. I have no idea if it is now. hg was horrible at git style branches wich are arguably a killer feature of git. I've heard they were grafted in to hg but you can go look up old tutorials on the net from say 2008 and see they were clearly not the norm for hg --- looked it up, the feature is called "bookmarks" and was added in 2010. And even after added, all tbe tutorials ignored them. no idea if they are the recommended workflow now but if not then you probably don't get why git is superior to hg
      - btreecat 3y ago
        Bookmarks were a wonderful feature and I used them all the time for release workflow. It was basically like tags in docker. Hg was indeed better than git, especially in the early days. But as git added features, made sane default choices more common, and cleaned up the CLI a bit, it doesn't matter now. They all do roughly the same thing, but the Hg workflow was still better imo because they just worked more intuitively coming from never using any DVCS before.
retpoline__ 3y ago
>The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used it more but - network effects! - used git because of the projects I was working on. I've recently wrote a post about it - how we're kinda locked with git and how other solutions have it hard to get adoption. git was good, but github cemented git's position. So unless GitHub allows other solutions, then we're kinda locked. >So what's the issue here? I'm worried that just because GitHub is so good, then unless they decouple from git as letters management engine and allow any/other, then we will be locked with git. https://trolololo.xyz/github https://trolololo.xyz/github
- naasking 3y ago
  > So unless GitHub allows other solutions I just use Mercurial with the git extension. Works fine.
anon23432343 3y ago
Say you dislike one peace of software because it does not have your used to mental model? okay sounds reasonable. Mercuiral booksmarks are strange to me and dont fit my mental model. Its like finding a bookmark for an article in my bookmark manger that I stored in some folder. So Random
- mark_undoio 3y ago
  I think one thing that helped git early on was that its concept of branches were just really convenient. For me I'd say it's that git doesn't fit my mental model and Mercurial does - it's that mercurial gave me a smaller mental model that (at least back when I used it heavily) allowed me to do what I needed. Even as a fairly experienced and advanced Git user, Git requires me to keep more state in the head and at, from my point of view, unpredictable times needs me to extend the model. The strange thing is that this is despite having a very simple model at the lowest levels of the system.
hannob 3y ago
Last time I checked every alternative to Git was lacking some major feature that would immediately make it a non-alternative to me. (And I wouldn't even remotely call myself a Git power user.) For Mercurial, that was shallow clones. I haven't looked at it in a while, but a quick googling shows me a wiki page where they discuss how an implementation could look like, and it hasn't been updated since 2015. Network effects are certainly a reason git is popular. But also: If you want to challenge git, you should be able to compete with its basic features.
- giraffe_lady 3y ago
  Fossil?
  - PH95VuimJjqBqy 3y ago
    no rebase, which for me is perfectly ok as I agree with the creator of Fossil wrt rebase. But it's definitely missing git's rebase :)
- failingslowly 3y ago
  Any of the non-distributed version control systems? /only ever so slightly s
- klodolph 3y ago
  Yeah. My workflow in Git centers on the index, and making lots of commits on local branches that will never get pushed. I spend a day working, rewrite history, stash a bunch of unrelated changes on temporary branches, and then send a couple commits on the main branch for code review. When I used Mercurial for work, it felt surreal to have all of those weird little workflows get locked away behind plugins. I get how Mercurial is way easier for people starting out, and I also get that I could just use the plugins, but when I use Git, all those history-rewriting tools are right there where I want them.
  - quleap 3y ago
    Mercurial, with its changeset evolution and phase management, is gazillions times more powerful than Git in terms of history rewriting.
Shorel 3y ago
> Sad to see another Mercurial holdout switch to Git. I am very happy when something like this happens. It means performance matters and a performant implementation is rewarded with market share. This performance is what made git win, even if the “porcelain”, the CLI commands we use, are not as well-designed as the ones in Mercurial. Hopefully one day we will no longer use any chat client written in Electron. =)
- rickydroll 3y ago
  > It means performance matters and a performant implementation is rewarded with market share. by this you mean technical group think or monoculture?
Shish2k 3y ago
I also find mercurial vastly more pleasant to use - nowadays I’m mostly using Sapling, since that’s basically mercurial’s frontend with the ability to speak the git protocol to git servers :)

deleted 3y ago

[deleted]

ocharles 3y ago

You might like https://github.com/martinvonz/jj https://github.com/martinvonz/jj, which gives an alternative frontend to Git.

mark_undoio 3y ago
Thanks - that looks interesting. It's especially appealing because it seems to add value beyond just being a neater wrapper to the same operations, it looks like it'll enable new ways of working with the tool.

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

pjmlp 3y ago

Yeah pour another glass for Mercurial, it is a shame that git ended up winning, but then again what to expect when it was a child of Linux kernel project.

bayindirh 3y ago
Some arguably* technically superior designs end up being obsoleted over time, because the arguably* inferior design ends up being more lined up with how people think and machines work. This is what we're seeing here, IMHO. *: There's nothing "objectively something" in computer science, because it's all is a pile trade-offs to get the desired result.
- The_Colonel 3y ago
  Well, can you explain why it applies here? Mercurial vs. Git is IMHO a textbook example of "good enough with large user base" beats "subtly superior with smaller user base" over the long term.
  - lovepronmostly 3y ago
    hg was not superior to git at v1. I have no idea if it is now. hg was horrible at git style branches wich are arguably a killer feature of git. I've heard they were grafted in to hg but you can go look up old tutorials on the net from say 2008 and see they were clearly not the norm for hg --- looked it up, the feature is called "bookmarks" and was added in 2010. And even after added, all tbe tutorials ignored them. no idea if they are the recommended workflow now but if not then you probably don't get why git is superior to hg
    - btreecat 3y ago
      Bookmarks were a wonderful feature and I used them all the time for release workflow. It was basically like tags in docker. Hg was indeed better than git, especially in the early days. But as git added features, made sane default choices more common, and cleaned up the CLI a bit, it doesn't matter now. They all do roughly the same thing, but the Hg workflow was still better imo because they just worked more intuitively coming from never using any DVCS before.

retpoline__ 3y ago

>The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used it more but - network effects! - used git because of the projects I was working on. I've recently wrote a post about it - how we're kinda locked with git and how other solutions have it hard to get adoption. git was good, but github cemented git's position. So unless GitHub allows other solutions, then we're kinda locked. >So what's the issue here? I'm worried that just because GitHub is so good, then unless they decouple from git as letters management engine and allow any/other, then we will be locked with git. https://trolololo.xyz/github https://trolololo.xyz/github

naasking 3y ago
> So unless GitHub allows other solutions I just use Mercurial with the git extension. Works fine.

anon23432343 3y ago

Say you dislike one peace of software because it does not have your used to mental model? okay sounds reasonable. Mercuiral booksmarks are strange to me and dont fit my mental model. Its like finding a bookmark for an article in my bookmark manger that I stored in some folder. So Random

mark_undoio 3y ago
I think one thing that helped git early on was that its concept of branches were just really convenient. For me I'd say it's that git doesn't fit my mental model and Mercurial does - it's that mercurial gave me a smaller mental model that (at least back when I used it heavily) allowed me to do what I needed. Even as a fairly experienced and advanced Git user, Git requires me to keep more state in the head and at, from my point of view, unpredictable times needs me to extend the model. The strange thing is that this is despite having a very simple model at the lowest levels of the system.

hannob 3y ago

Last time I checked every alternative to Git was lacking some major feature that would immediately make it a non-alternative to me. (And I wouldn't even remotely call myself a Git power user.) For Mercurial, that was shallow clones. I haven't looked at it in a while, but a quick googling shows me a wiki page where they discuss how an implementation could look like, and it hasn't been updated since 2015. Network effects are certainly a reason git is popular. But also: If you want to challenge git, you should be able to compete with its basic features.

giraffe_lady 3y ago
Fossil?
- PH95VuimJjqBqy 3y ago
  no rebase, which for me is perfectly ok as I agree with the creator of Fossil wrt rebase. But it's definitely missing git's rebase :)
failingslowly 3y ago
Any of the non-distributed version control systems? /only ever so slightly s
klodolph 3y ago
Yeah. My workflow in Git centers on the index, and making lots of commits on local branches that will never get pushed. I spend a day working, rewrite history, stash a bunch of unrelated changes on temporary branches, and then send a couple commits on the main branch for code review. When I used Mercurial for work, it felt surreal to have all of those weird little workflows get locked away behind plugins. I get how Mercurial is way easier for people starting out, and I also get that I could just use the plugins, but when I use Git, all those history-rewriting tools are right there where I want them.
- quleap 3y ago
  Mercurial, with its changeset evolution and phase management, is gazillions times more powerful than Git in terms of history rewriting.

Shorel 3y ago

> Sad to see another Mercurial holdout switch to Git. I am very happy when something like this happens. It means performance matters and a performant implementation is rewarded with market share. This performance is what made git win, even if the “porcelain”, the CLI commands we use, are not as well-designed as the ones in Mercurial. Hopefully one day we will no longer use any chat client written in Electron. =)

rickydroll 3y ago
> It means performance matters and a performant implementation is rewarded with market share. by this you mean technical group think or monoculture?

Shish2k 3y ago

I also find mercurial vastly more pleasant to use - nowadays I’m mostly using Sapling, since that’s basically mercurial’s frontend with the ability to speak the git protocol to git servers :)