11 ms·

Ah, there it is. I was wondering when this would happen. Facebook used to be involved with the Mercurial community, but it was difficult to work with them. The

Ah, there it is. I was wondering when this would happen. Facebook used to be involved with the Mercurial community, but it was difficult to work with them. They always wanted to do things their way, had their own intentions, and started to demand that the Mercurial project work the way that Facebook wanted. For example, they demanded that we start using Phabricator and started slowly removing sequential revisions from Mercurial in favour of always using node hashes everywhere, arguing that for their gigantic repos, sequential revisions were so big as to be useless. Eventually the disagreements were too great, and Facebook just stopped publicly talking about Mercurial. I figured they would emerge a few years later with their fork of it. They love doing this. HipHop VM for PHP, Apache Hive, MyRock; these are examples of Facebook forking off their development in private and then later emerging with some thing they built on top of it. The Mercurial project is surprisingly still chugging along, and there are still those of us who actually use Mercurial. I doubt I'll switch over to Sapling, because I disagreed with the things that made Facebook fork off in the first place. But if others like Sapling and this manages to put the slightest dent into the git monoculture, I'm happy for the change and innovation. I really hope that git is not the final word in version control. I want to see more ideas be spread and that people can see that there can be a world beyond git.

layer8 4y ago
> I disagreed with the things that made Facebook fork off in the first place. Could you elaborate on what these things are and why you disagree with them?
- ravi-delia 4y ago
  Presumably the things listed in the second paragraph (Phabricator, node hashes)
IshKebab 4y ago
I was going to say that they already had started their own successor to Mercurial called Eden, but it seems like Sapling is just a renaming of Eden. Maybe anyway. It's a bit unclear.
- aseipp 4y ago
  Yeah, the old Eden repository redirects directly to Sapling now: https://github.com/facebookexperimental/eden https://github.com/facebookexperimental/eden
- mitrandir77 4y ago
  https://news.ycombinator.com/item?id=33615077 https://news.ycombinator.com/item?id=33615077
- sheepscreek 4y ago
  From the repo readme: > The Sapling CLI, sl, was originally based on Mercurial, and shares various aspects of the UI and features of Mercurial.
- glandium 4y ago
  From the build instructions for sapling: "It can be built by running make oss in the eden/scm directory"
  - mdaniel 4y ago
    Holy hell, did they manually recreate meson? a 1700 line setup.py ... https://github.com/facebook/sapling/blob/main/eden/scm/setup.py#L1728 https://github.com/facebook/sapling/blob/main/eden/scm/setup... It's a pet peeve of mine folks that use python subprocess as a replacement for bash because it takes special discipline to not eat stdout and stderr, or to correctly try:finally: to show the Proc details before the raise eats the variable
    - bitexploder 4y ago
      Use python doit system if you need what this setup.py is doing. Its a great task and build system.
  - glandium 4y ago
    I hadn't looked at the eden/scm directory, but they didn't even bother to change the README to not say "Mercurial" https://github.com/facebook/sapling/tree/main/eden/scm https://github.com/facebook/sapling/tree/main/eden/scm
TazeTSchnitzel 4y ago
As someone who used to be intimately involved in the development of PHP, HHVM was an interesting project because for a long time it supported standard PHP (alongside Facebook's custom language, Hack), so it brought competition to the implementation space! But eventually Facebook lost interest in that part, probably because they had no use for it.
- Shish2k 4y ago
  If Sapling encourages a Git-usability renaissance the same way HHVM encouraged PHP to get good performance and typing, even if it eventually gets abandoned, I will be thankful for it :)
alwillis 4y ago
I certainly recognized several Mercurial features and concepts in Sapling. For example, I use Mercurial’s absorb command [1] and was pleased to see it in Sapling. Overall this looks promising. [1]: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-changes-in-mercurial-4.8/ https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-ch...
- jordigh 4y ago
  Absorb is fantastic and one of Jun Wu's (seen in this thread as quark12) best contributions to Mercurial. I want everyone to know about this tool, it's amazing. I had fun trying to come up with a name for the feature: https://lobste.rs/s/nws1uj/help_us_name_new_mercurial_feature https://lobste.rs/s/nws1uj/help_us_name_new_mercurial_featur...
- sweettea 4y ago
  Absorb is amazing! Even if you don't take up Sapling, there's a 'git absorb' plugin which I have found absolutely invaluable: https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb
  - madsohm 4y ago
    Just learned about 'git absorb' couple of weeks ago and have used it every day since. Amazing tool.
  - boredtofears 4y ago
    Holy crap that looks incredible. I can't wait to try this.
  - hakre 4y ago
    thanks for the reference, using `git-fixup` myself since years: https://github.com/keis/git-fixup https://github.com/keis/git-fixup Will try `git-absorb`.
- Too 4y ago
  In git you do this like git commit --fixup hashtofix && git rebase -i --autosquash hashtofix^ Hard to discover and remember but once you do it usually works smoothly.
kmavm 4y ago
Slight correction: HipHop for PHP was cleanroom, including rewriting large families of native extensions to work with its C++ runtime, although it eventually developed workalikes for the PHP dev headers to ease development. Source: I worked on HHVM, its JIT successor that initially shared its source tree and runtime.
- astrange 4y ago
  Facebook developers seem to have a surprising amount of free time to go around reinventing things that are not obviously social network features. (Or to have had it in the 2010s, at least.)
  - saagarjha 4y ago
    It's not particularly surprising that a surprising amount of infrastructure is needed to run a social network.
    - astrange 4y ago
      Note WhatsApp had 35 employees when they were acquired and Instagram had 13. At that size you need to be productive at managing servers but you're probably not thinking how great it'd be to have a "whole new programming language and source control system" team.
      - saagarjha 4y ago
        WhatsApp and Instagram at the point of acquisition were simpler than Facebook is (and was), or even compared to what it is now. Once you scale you start to need a lot of engineers to help keep things standing up and everyone on the same page.
        Cederfjard 4y ago
        WhatsApp had like half a billion monthly active users when they were acquired, that could be considered fairly large scale, no? But I agree with your point in general.
jkaptur 4y ago
I switched from git to Mercurial and was absolutely gobsmacked by how much better it is. The only comparison was switching from a Blackberry to an iPhone - everything just works exactly the way I want it to. Yes, I read the manual for git, but I never needed to for Mercurial.
- baud147258 4y ago
  Having used svn, git, mercurial then back to git (with the last two at the same job, the business unit having decided to move from mercurial to a git-based solution) and I've preferred mercurial to git, where it feels like there's more possible foot-guns and its features don't bring enough value to justify the increased complexity when using it .
- riquito 4y ago
  I guess you didn't start from cvs or svn, because the experience moving to git was otherworldly. If git was your first versioning system than you had to learn some concepts first, which you already internalized when you switched to Mercurial.
  - jkaptur 4y ago
    No, I started with SVN and (briefly) VSS. I did use git for a while before hg, though, so I guess what you’re saying is possible.
  - Tomis02 4y ago
    Due to my workplace I moved from svn to hg (awesome experience) and then from hg to git (terrible experience). That was years ago, and the git experience remains terrible.
    - Varriount 4y ago
      Can you elucidate? What did you find appealing/unappealing?
      - 4y ago
Remnant44 4y ago
The way Mercurial is structured is, to me, intuitive, easy, and powerful. I'm still using it for all of my local projects; luckily hg-git lets you pull in dependencies from github, which would otherwise require me to switch to git. I wish it had won the DVCS wars.
matheusmoreira 4y ago
> started to demand that the Mercurial project work the way that Facebook wanted Seems to be a recurring pattern when people interact with open source communities. Why does it have to be like this? It's not just companies either...
- bitexploder 4y ago
  I have been using fossil for my own local projects. Super easy to set the fossil UI up behind nginx for small teams. Been enjoying it.
- josephg 4y ago
  > Why does it have to be like this? Because motivated, high performing people need to have control over their own destiny. Because cookie-cutter solutions which work for 90% of use cases are often worse than something explicitly tuned for you. People having specific needs, getting frustrated and then solving their problem is a feature of opensource code. Its not a bug. It is the engine of innovation and improvement. Forking means we can both get what we want, even if our needs are contradictory or we don't want to work together. This happens with commercial offerings too - but its a mess. You can't just fork the code without paying (or sometimes at all). And every fork is private, so work is duplicated and collective learning doesn't happen. Expensive consulting-ware might be the best case outcome. The ability of motivated people to fork projects and have their own spin on things is one of the biggest strengths of opensource. May the best forks win.
  - matheusmoreira 4y ago
    Does it have to be so disrespectful, though? Demanding things, getting frustrated when denied and ghosting the original project to the point even they are surprised when a fork shows up?
    - mmsimanga 4y ago
      There is always too sides to a story. We don't know what pressures the FB engineers were under and the problems they were trying to solve resulting in them "demanding" changes. In the end I think everyone wins with the forking.
NERD_ALERT 4y ago
Fossil is a pretty great alternative to git. https://www.fossil-scm.org/home/doc/trunk/www/index.wiki https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
- bolangi 4y ago
  One design choice in fossil is not to allow rewriting history, in other words, no rebase. Justified in "Rebase Considered Harmful" at https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md .
- 112233 4y ago
  Has anyone successfully imported Linux kernel git into fossil? I'm interested to hear how that was done, my attempts never terminated...
deleted 4y ago
[deleted]
bjarneh 4y ago
> and there are still those of us who actually use Mercurial I'm certainly in that camp; and it pains me every time I have to use the hggit extension to convert a mercurial repo to git in order to work with everyone else...
- ezst 4y ago
  Yeah, we should give a shout-out to the octobus folks for making heptapod, a Gitlab fork bringing support for mercurial repos. That brings at least one mainstream hosting option for hg repos.
  - bjarneh 4y ago
    Absolutely. I guess most of us have a bunch of repos which are personal anyway which are just as easily "hosted" as Mercurial repos. I.e. if I have ssh access to a machine, "hosting" a remote Mercurial repo with hg init instead of git init --bare does not matter to much..
deleted 4y ago
[deleted]
throwawaaarrgh 4y ago
> I really hope that git is not the final word in version control. common problem in open source. any project that gets big enough effectively stops anyone from wanting to work on an alternative, or use an alternative, due to the momentum of the large project. deviating from it makes it harder to collaborate or be productive because the big project does everything (though often poorly), everyone knows it already, and no one wants to learn something new, and no one wants to work with the people using the weird thing. same reason why it's hard to make a Facebook alternative.
- ezst 4y ago
  That's true, but that's not the whole story either. I remember not too long ago when it wasn't a big deal to jump from one VCS to another. Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard, would go from mailing patches to a ML on a project to pushing to a repo on another, to zipping code and uploading it on a FTP on a third. It was the project's workflow of choice, and people would respect that. Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive. We peer-pressured ourselves into collectively using a less-than-ideal tech because that was the price to pay to belong.
  - CRConrad 4y ago
    The big baddie here, IMO, isn't even git itself but GitHub. Many younger devs don't even seem to realise that they're not the same thing, that git can be used without GitHub.
  - aseipp 4y ago
    > Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard That's completely made up on your end. I've been doing FOSS for 17 years and the vast majority of people were barely competent with any of them at all beyond whatever their chosen ponyshow was (including off-brand ones like Darcs and Monotone), and any switching from a persons preferred one to the use of another project was often met with grunting and complaining, if it was done at all. The reality is we only think this because we saw people do this, at great cost of their own time -- but that's the literal definition of survivalship bias. For every 1 person doing this 50 just stuck with whatever they used and wouldn't bother. I've literally seen people refuse to contribute to a project over tabs vs spaces, and people still do this with git vs hg today, just not as much today. More people use Git and contribute to FOSS in a single day in 2022 than every developer who knew all these tools combined back in 2008 or whatever. Whether this is good or bad is up to you, but you don't need to make up claims about developers being epic journeymen in the past and mastering 50 version control tools to do a single days work. They did not. > Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive. Sorry, but I consider this to be a similarly made up claim that's just sour grapes. I've been using GitHub since 2008, I'm one of the first users. GitHub didn't even have "gamified" social features until the past 3-4 years IME (what, stars are about it?), and before that its product was pretty poor in some key areas like code review and project management, org permissions, on-prem control, etc. I didn't even use GitHub commercially until like, 2018, because most orgs had setups that were better in some key areas. But it was pretty easy to use and get started with, which mattered, and still matters, and soon enough nobody could compete with the same ease of use for free projects. If I had to "blame" "someone" in this vein, a better place to start: global monetary and fiscal policy for the past 20 years resulting in software development becoming one of the only places with rising wages to meet cost of living demands in places like the US -- resulting in an influx of new blood to increase their wages and quality of life, combined with political choices like low interest rates, and huge explosions in demand for software devs for things like VC adventures, etc. Subsequent developments like bootcamps designed to churn devs out to match rising demand, etc which solidified platforms like GitHub further as it was easier for them to paper over these fundamentals when there was a clear winner (git/github) to focus on and ignore everything else. Forest vs trees and all.
zestyping 4y ago
Mercurial has a far better user experience and mental model. The commonly used commands simply do what their names say: hd add, hg commit, hg revert, hg update, and so on. Git is a twisty maze of operations combined under poor names (e.g. git reset) with dozens of obscure options (e.g. man git-log) and broken abstractions (e.g. what is HEAD and why does Git emit a warning whenever I check out a tag?). I often feel so sad that the entire software industry has fallen to Stockholm syndrome under Git — we think these contortions are normal, when in fact they are arcane.

layer8 4y ago

> I disagreed with the things that made Facebook fork off in the first place. Could you elaborate on what these things are and why you disagree with them?

ravi-delia 4y ago
Presumably the things listed in the second paragraph (Phabricator, node hashes)

IshKebab 4y ago

I was going to say that they already had started their own successor to Mercurial called Eden, but it seems like Sapling is just a renaming of Eden. Maybe anyway. It's a bit unclear.

aseipp 4y ago
Yeah, the old Eden repository redirects directly to Sapling now: https://github.com/facebookexperimental/eden https://github.com/facebookexperimental/eden
mitrandir77 4y ago
https://news.ycombinator.com/item?id=33615077 https://news.ycombinator.com/item?id=33615077
sheepscreek 4y ago
From the repo readme: > The Sapling CLI, sl, was originally based on Mercurial, and shares various aspects of the UI and features of Mercurial.
glandium 4y ago
From the build instructions for sapling: "It can be built by running make oss in the eden/scm directory"
- mdaniel 4y ago
  Holy hell, did they manually recreate meson? a 1700 line setup.py ... https://github.com/facebook/sapling/blob/main/eden/scm/setup.py#L1728 https://github.com/facebook/sapling/blob/main/eden/scm/setup... It's a pet peeve of mine folks that use python subprocess as a replacement for bash because it takes special discipline to not eat stdout and stderr, or to correctly try:finally: to show the Proc details before the raise eats the variable
  - bitexploder 4y ago
    Use python doit system if you need what this setup.py is doing. Its a great task and build system.
- glandium 4y ago
  I hadn't looked at the eden/scm directory, but they didn't even bother to change the README to not say "Mercurial" https://github.com/facebook/sapling/tree/main/eden/scm https://github.com/facebook/sapling/tree/main/eden/scm

TazeTSchnitzel 4y ago

As someone who used to be intimately involved in the development of PHP, HHVM was an interesting project because for a long time it supported standard PHP (alongside Facebook's custom language, Hack), so it brought competition to the implementation space! But eventually Facebook lost interest in that part, probably because they had no use for it.

Shish2k 4y ago
If Sapling encourages a Git-usability renaissance the same way HHVM encouraged PHP to get good performance and typing, even if it eventually gets abandoned, I will be thankful for it :)

alwillis 4y ago

I certainly recognized several Mercurial features and concepts in Sapling. For example, I use Mercurial’s absorb command [1] and was pleased to see it in Sapling. Overall this looks promising. [1]: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-changes-in-mercurial-4.8/ https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-ch...

jordigh 4y ago
Absorb is fantastic and one of Jun Wu's (seen in this thread as quark12) best contributions to Mercurial. I want everyone to know about this tool, it's amazing. I had fun trying to come up with a name for the feature: https://lobste.rs/s/nws1uj/help_us_name_new_mercurial_feature https://lobste.rs/s/nws1uj/help_us_name_new_mercurial_featur...
sweettea 4y ago
Absorb is amazing! Even if you don't take up Sapling, there's a 'git absorb' plugin which I have found absolutely invaluable: https://github.com/tummychow/git-absorb https://github.com/tummychow/git-absorb
- madsohm 4y ago
  Just learned about 'git absorb' couple of weeks ago and have used it every day since. Amazing tool.
- boredtofears 4y ago
  Holy crap that looks incredible. I can't wait to try this.
- hakre 4y ago
  thanks for the reference, using `git-fixup` myself since years: https://github.com/keis/git-fixup https://github.com/keis/git-fixup Will try `git-absorb`.
Too 4y ago
In git you do this like git commit --fixup hashtofix && git rebase -i --autosquash hashtofix^ Hard to discover and remember but once you do it usually works smoothly.

kmavm 4y ago

Slight correction: HipHop for PHP was cleanroom, including rewriting large families of native extensions to work with its C++ runtime, although it eventually developed workalikes for the PHP dev headers to ease development. Source: I worked on HHVM, its JIT successor that initially shared its source tree and runtime.

astrange 4y ago
Facebook developers seem to have a surprising amount of free time to go around reinventing things that are not obviously social network features. (Or to have had it in the 2010s, at least.)
- saagarjha 4y ago
  It's not particularly surprising that a surprising amount of infrastructure is needed to run a social network.
  - astrange 4y ago
    Note WhatsApp had 35 employees when they were acquired and Instagram had 13. At that size you need to be productive at managing servers but you're probably not thinking how great it'd be to have a "whole new programming language and source control system" team.
    - saagarjha 4y ago
      WhatsApp and Instagram at the point of acquisition were simpler than Facebook is (and was), or even compared to what it is now. Once you scale you start to need a lot of engineers to help keep things standing up and everyone on the same page.
      - Cederfjard 4y ago
        WhatsApp had like half a billion monthly active users when they were acquired, that could be considered fairly large scale, no? But I agree with your point in general.

jkaptur 4y ago

I switched from git to Mercurial and was absolutely gobsmacked by how much better it is. The only comparison was switching from a Blackberry to an iPhone - everything just works exactly the way I want it to. Yes, I read the manual for git, but I never needed to for Mercurial.

baud147258 4y ago
Having used svn, git, mercurial then back to git (with the last two at the same job, the business unit having decided to move from mercurial to a git-based solution) and I've preferred mercurial to git, where it feels like there's more possible foot-guns and its features don't bring enough value to justify the increased complexity when using it .
riquito 4y ago
I guess you didn't start from cvs or svn, because the experience moving to git was otherworldly. If git was your first versioning system than you had to learn some concepts first, which you already internalized when you switched to Mercurial.
- jkaptur 4y ago
  No, I started with SVN and (briefly) VSS. I did use git for a while before hg, though, so I guess what you’re saying is possible.
- Tomis02 4y ago
  Due to my workplace I moved from svn to hg (awesome experience) and then from hg to git (terrible experience). That was years ago, and the git experience remains terrible.
  - Varriount 4y ago
    Can you elucidate? What did you find appealing/unappealing?
    - 4y ago

Remnant44 4y ago

The way Mercurial is structured is, to me, intuitive, easy, and powerful. I'm still using it for all of my local projects; luckily hg-git lets you pull in dependencies from github, which would otherwise require me to switch to git. I wish it had won the DVCS wars.

matheusmoreira 4y ago

> started to demand that the Mercurial project work the way that Facebook wanted Seems to be a recurring pattern when people interact with open source communities. Why does it have to be like this? It's not just companies either...

bitexploder 4y ago
I have been using fossil for my own local projects. Super easy to set the fossil UI up behind nginx for small teams. Been enjoying it.
josephg 4y ago
> Why does it have to be like this? Because motivated, high performing people need to have control over their own destiny. Because cookie-cutter solutions which work for 90% of use cases are often worse than something explicitly tuned for you. People having specific needs, getting frustrated and then solving their problem is a feature of opensource code. Its not a bug. It is the engine of innovation and improvement. Forking means we can both get what we want, even if our needs are contradictory or we don't want to work together. This happens with commercial offerings too - but its a mess. You can't just fork the code without paying (or sometimes at all). And every fork is private, so work is duplicated and collective learning doesn't happen. Expensive consulting-ware might be the best case outcome. The ability of motivated people to fork projects and have their own spin on things is one of the biggest strengths of opensource. May the best forks win.
- matheusmoreira 4y ago
  Does it have to be so disrespectful, though? Demanding things, getting frustrated when denied and ghosting the original project to the point even they are surprised when a fork shows up?
  - mmsimanga 4y ago
    There is always too sides to a story. We don't know what pressures the FB engineers were under and the problems they were trying to solve resulting in them "demanding" changes. In the end I think everyone wins with the forking.

NERD_ALERT 4y ago

Fossil is a pretty great alternative to git. https://www.fossil-scm.org/home/doc/trunk/www/index.wiki https://www.fossil-scm.org/home/doc/trunk/www/index.wiki

bolangi 4y ago
One design choice in fossil is not to allow rewriting history, in other words, no rebase. Justified in "Rebase Considered Harmful" at https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md .
112233 4y ago
Has anyone successfully imported Linux kernel git into fossil? I'm interested to hear how that was done, my attempts never terminated...

deleted 4y ago

[deleted]

bjarneh 4y ago

> and there are still those of us who actually use Mercurial I'm certainly in that camp; and it pains me every time I have to use the hggit extension to convert a mercurial repo to git in order to work with everyone else...

ezst 4y ago
Yeah, we should give a shout-out to the octobus folks for making heptapod, a Gitlab fork bringing support for mercurial repos. That brings at least one mainstream hosting option for hg repos.
- bjarneh 4y ago
  Absolutely. I guess most of us have a bunch of repos which are personal anyway which are just as easily "hosted" as Mercurial repos. I.e. if I have ssh access to a machine, "hosting" a remote Mercurial repo with hg init instead of git init --bare does not matter to much..

deleted 4y ago

[deleted]

throwawaaarrgh 4y ago

> I really hope that git is not the final word in version control. common problem in open source. any project that gets big enough effectively stops anyone from wanting to work on an alternative, or use an alternative, due to the momentum of the large project. deviating from it makes it harder to collaborate or be productive because the big project does everything (though often poorly), everyone knows it already, and no one wants to learn something new, and no one wants to work with the people using the weird thing. same reason why it's hard to make a Facebook alternative.

ezst 4y ago
That's true, but that's not the whole story either. I remember not too long ago when it wasn't a big deal to jump from one VCS to another. Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard, would go from mailing patches to a ML on a project to pushing to a repo on another, to zipping code and uploading it on a FTP on a third. It was the project's workflow of choice, and people would respect that. Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive. We peer-pressured ourselves into collectively using a less-than-ideal tech because that was the price to pay to belong.
- CRConrad 4y ago
  The big baddie here, IMO, isn't even git itself but GitHub. Many younger devs don't even seem to realise that they're not the same thing, that git can be used without GitHub.
- aseipp 4y ago
  > Devs were proficient in CVS, SVN, HG, BZR, GIT as a standard That's completely made up on your end. I've been doing FOSS for 17 years and the vast majority of people were barely competent with any of them at all beyond whatever their chosen ponyshow was (including off-brand ones like Darcs and Monotone), and any switching from a persons preferred one to the use of another project was often met with grunting and complaining, if it was done at all. The reality is we only think this because we saw people do this, at great cost of their own time -- but that's the literal definition of survivalship bias. For every 1 person doing this 50 just stuck with whatever they used and wouldn't bother. I've literally seen people refuse to contribute to a project over tabs vs spaces, and people still do this with git vs hg today, just not as much today. More people use Git and contribute to FOSS in a single day in 2022 than every developer who knew all these tools combined back in 2008 or whatever. Whether this is good or bad is up to you, but you don't need to make up claims about developers being epic journeymen in the past and mastering 50 version control tools to do a single days work. They did not. > Things really became one-sided after github started gamifying open-source contributions, and when a new generation who perhaps grew-up in a more competitive academic setting took it as an opportunity to make their resume more impressive. Sorry, but I consider this to be a similarly made up claim that's just sour grapes. I've been using GitHub since 2008, I'm one of the first users. GitHub didn't even have "gamified" social features until the past 3-4 years IME (what, stars are about it?), and before that its product was pretty poor in some key areas like code review and project management, org permissions, on-prem control, etc. I didn't even use GitHub commercially until like, 2018, because most orgs had setups that were better in some key areas. But it was pretty easy to use and get started with, which mattered, and still matters, and soon enough nobody could compete with the same ease of use for free projects. If I had to "blame" "someone" in this vein, a better place to start: global monetary and fiscal policy for the past 20 years resulting in software development becoming one of the only places with rising wages to meet cost of living demands in places like the US -- resulting in an influx of new blood to increase their wages and quality of life, combined with political choices like low interest rates, and huge explosions in demand for software devs for things like VC adventures, etc. Subsequent developments like bootcamps designed to churn devs out to match rising demand, etc which solidified platforms like GitHub further as it was easier for them to paper over these fundamentals when there was a clear winner (git/github) to focus on and ignore everything else. Forest vs trees and all.

zestyping 4y ago

Mercurial has a far better user experience and mental model. The commonly used commands simply do what their names say: hd add, hg commit, hg revert, hg update, and so on. Git is a twisty maze of operations combined under poor names (e.g. git reset) with dozens of obscure options (e.g. man git-log) and broken abstractions (e.g. what is HEAD and why does Git emit a warning whenever I check out a tag?). I often feel so sad that the entire software industry has fallen to Stockholm syndrome under Git — we think these contortions are normal, when in fact they are arcane.