17 ms·

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,

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!

avarun 4mo ago
Around 20 years ago Facebook made the same choice, so you're in good company in terms of technically sophisticated shops.
- loeg 4mo 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 4mo ago
    You can use all the normal hg commands at Meta. It’s a regular mercurial repo from the standpoint of a user
    - loeg 4mo ago
      Yeah, but people using open source mercurial aren't in the same boat. It's a different codebase.
- zeroonetwothree 4mo ago
  Facebook didn’t adopt mercurial until something like 2014? And before that used svn -> git
woadwarrior01 4mo 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.
tempest_ 4mo ago
Our company also made this choice. One of the first things I did was switch us to git. Mercurial was way easier to use and fit our use case but all the tooling was built for git.
amluto 4mo ago
I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. But it was not all amazing: Mercurial’s branching model was very poor, and its sequentially numbered revision system was and remains a very bad design.
- locknitpicker 4mo ago
  > I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches, of even we could perhaps install a module such as shelve. That was the image that Mercurial left with me with regards to git: missing critical features and not bothering to bridge the gap.
  - marcher 4mo ago
    It did have a kind of equivalent to stashes in the mq extension, but its interface was a bit esoteric compared to the rest of Hg, from what I remember.
    - voidnap 4mo ago
      A lot of features that git had by default had to be enabled as plugins in mercurial. The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off. I think some of the extensions were very basic stuff like graph logging and colorized output -- and mq like you said. So it was kind of unfortunate that people got a bad impression of hg from that and bounced off.
      - locknitpicker 4mo ago
        > The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off. It goes a little deeper than that. Prospective Mercurial users who wanted a specific feature were first greeted with claims that they were in the wrong for even entertaining the idea they needed such a thing. The rationale was that Mercurial already did everything they could possibly wanted to do, and so by definition wanting to do something differently was proof the user was in the wrong. But to stop hearing about how feature X or Y was needed, they could roll out their own extension and leave the project alone and not bother them with these silly things. Shipping extensions by default is an absurdity, once you think about it. It's effectively a way to disable features by default and stop hearing about how the project needs to support a feature. And that's how Mercurial dealt with it's potential user base.
justsomehnguy 4mo ago
You did the right at the right time, you wasn't some prescient being. Why are you
3form 4mo ago
I'm glad that I stuck to git for a similar reason; it won the war. And I understand the need for simpler tools. But to offer a point I haven't heard from anyone before: at least I feel that I am done with it, I learned this tool sufficiently and I can move on with my life. From time to time I add something to my git toolbelt. I feel if Mercurial or anything else have won, I would maybe have to learn another tool in 5 years, whatever else got popular, and another in next 5 years. But now I have everything I need in git, and always have needed. I hold some hope in it that perhaps the learning curve was worth it.
- MBCook 4mo ago
  That’s a great point I hadn’t thought of before. I’m glad there is one clear winner and we’re not in the common position of having 2-3 relevant/semi-relevant choices that you’re frequently asked to switch between depending on which project you’re looking at at the moment. Git is modern version control, whatever you think of it, and there’s a simplicity to that.
- esafak 4mo ago
  Despite not using anything else, I don't know all the git commands I need to get my job done so I use UIs and my agent. It's just not intuitive enough, some things are just not possible to do right, and I look forward to ditching it.
  - pif 4mo ago
    > some things are just not possible to do right If git doesn't let you do them "right", your concept if "right" is wrong.
qwery 4mo ago
I don't think Git winning a popularity contest is a reason for choosing Mercurial to have been wrong, or unfortunate. Was there some negative consequence from the decision -- either directly from Mercurial itself, or just because over time everyone expected Git, perhaps? (Hopefully this comes across as curious, which it is, and not antagonistic, which its not)
- MBCook 4mo ago
  Not GP but there is a consequence. These days if someone has used version control they almost certainly know Git. That means pretty much everyone who comes in the door needs Mercurial training, whether formal or informal. You’d get the same effect from still using CVS, SVN, or other things. That may not be a big issue. If someone understands version control I’d hope they could adapt to another minder pretty fast. It’s still an issue. There is technically a cost.
  - gmueckl 4mo ago
    There is an initial cost to learning hg, but it is usually offset by the less destructive nature of hg's behaviors and defaults in the long term.
yegle 4mo ago
I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects, and that is changing given the sad state of GitHub. Another contender is Jujutsu (jj) which allows you to use jj as frontend and use Git as the backend (with the potential to support any backend, e.g. Google's proprietary Piper), with the best ergonomic and the widest availability of hosting solutions.
- ncphillips 4mo ago
  I’ve recently switched to jj and it is truly amazing. It too about a week for me to “get it”. The tool is amazing but I think there’s way too much emphasis on what it does/allows rather than what benefits it brings to your workflow. If they get that marketing right I could see it growing. If not, I’ll keep using it
  - j_bum 4mo ago
    Would you be willing to pitch why you like jj and find it useful? How were you using git? I use git mostly on single-dev projects, with branched development patterns. Would someone like me with a simple git use-case find JJ enjoyable?
    - kaeshiwaza 4mo ago
      jj is amazing, even as a solo dev on small projects. It's difficult to explain because it depends of each usage, but it's very easy and safe (you can undo everything) to just try and see.
- lmm 4mo ago
  > I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects Nah. At the time BitBucket was the better way to do open source projects, and they were Mercurial-first. But eventually they had to add Git support because there was so much demand.
jjav 4mo ago
Mercurial is one of the many sad stories of far better technology being forgotten by the popularity contest juggernaut of something else. I still use mercurial for all my personal project where I don't need to care what anyone else thinks. It is pleasant to use good tools, just like I like to buy top quality rachets or such.
- loeg 4mo ago
  Mercurial wasn't the better technology, though. The UX is almost the same as git, diverging in ways that are arguably worse, but the tools were written in much slower Python (initially, and for many years after).
  - dijit 4mo ago
    Writing your tooling in python is valid while starting out and prototyping. One of the big criticisms I've seen levied against Rust is that refactoring is extremely difficult, so prototyping on ideas in the language itself is a poor experience. I've personally had great success using python, then gradually rewriting the tool I have with py03 to "oxidise" the program iteratively. Starting with C was great for performance of Git, but damn if it's not a terrible UX these days, I can believe that the choice of toolchain and language was a contributor to that fact.
    - IshKebab 4mo ago
      > Writing your tooling in python is valid while starting out and prototyping. This fallacy again. Tell me, when did Mercurial decide "ok the prototype is done, we'll rewrite it in a proper language"? They didn't, of course. Because nobody ever does. Your "prototype" gradually becomes a 100k line product that you can't afford to rewrite. (I guess you can YOLO it with AI these days but that wasn't an option for Mercurial.) > Starting with C was great for performance of Git, but damn if it's not a terrible UX these days Git's terrible UX doesn't have anything to do with C. C doesn't make you always pick a different flag for "delete".
      - deleted 4mo ago
fHr 4mo ago
meanwhile my org still uses svn for a lot of repos at least my teams are full git...ugh
martin-t 4mo ago
I hate that social factors like popularity are a thing in technical decisions. I have not used mercurial (though heard good things about it) but I saw a similar thing play out in Rust gamedev. There are 2 competing game engines, one better technically, the other much more popular. Now, if everyone made a purely technical decision, they'd pick the first one and eventually it would become the more popular one. Unfortunately, whenever I asked people why they chose the second one, they said because it was more popular. Tragedy of the commons. If it's any consolation, maybe jj will take over. I haven't tried it yet (I use the staging area a lot in my workflow), but AFAIK they made the choice to be git-compatible which means it's not a choice between one or the other but lets people and teams migrate gradually.
- Shish2k 4mo ago
  FWIW you can still have a staging-area-like workflow with JJ - it's just that while git has "commits", "the staging area", "the working directory", and "stashes" as four separate concepts with four separate toolkits, in JJ all of those things are "commits" and a single toolkit works with all of them :)
  - martin-t 4mo ago
    I hoped that would be possible but wasn't sure, thanks.
- HWR_14 4mo ago
  > Tragedy of the commons That's a different concept. You are describing network effects.
foresto 4mo ago
> I helped them make the wrong choice, Mercurial. 20 years ago, Mercurial was not the wrong choice. - Its internal design was very similar to Git's. - Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.) - Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model. - (It had a third major advantage over Git that I unfortunately cannot recall at the moment.) So you weren't wrong back then... ...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.
- ciupicri 4mo ago
  I don't know what you mean by ergonomics, but I remember trying both Mercurial and Git back in the days after using Subversion before. I didn't like how Mercurial didn't easily let me rewrite history and do stuff like `git commit --ammend` or `git rebase`. Mercurial users kept telling me using an extension to manage patches on top of Mercurial (I think it was quilt). I agree about the Windows support. hg serve was also nice. Plus TortoiseHg.
  - thfuran 4mo ago
    Mercurial does let you amend commits like git does, histedit is essentially identical to rebase -i, and evolve is better than anything git has.
    - ciupicri 4mo ago
      Isn't histedit [1] an extension? I don't think it was available back then, or if I tried I didn't like it. I don't remember evolve [2] at all. [1]: https://repo.mercurial-scm.org/hg/help/histedit https://repo.mercurial-scm.org/hg/help/histedit [2]: https://repo.mercurial-scm.org/hello/help/evolve https://repo.mercurial-scm.org/hello/help/evolve
dismalaf 4mo ago
I used Mercurial back in the day too. I agree, it was better. That being said, GitHub was better than other similar services which no doubt helped git win and now, git is ubiquitous.
sampo 4mo ago
> But I guess I couldn't read the future in terms of which one would win out! After Linus Torvalds gave this talk at Google in 2007, it was clear he would win. (Is there a better quality video somewhere?) https://www.youtube.com/watch?v=idLyobOhtO4 https://www.youtube.com/watch?v=idLyobOhtO4 But I agree: Mercurial was definitely friendlier for people who didn't have time time to go through the technicalities of git. To use git smoothly you pretty much need to learn how it works internally.
- PunchyHamster 4mo ago
  To be entirely fair nothing in git backend prevents someone to make friendlier frontend.
  - gabrielhidasy 4mo ago
    Case in point is Magit, I use Mercurial almost every day at work so git got a bit unfamiliar, but Magit is still more natural then mercurial for me.
squirrellous 4mo ago
Both Facebook and Google internally use a custom version of mercurial, so I wouldn’t count it out just yet.
vogelke 4mo ago
Best part about open source -- Mercurial is still around, I use it for my home servers, and it's being maintained. I can use git, but Mercurial's workflow just makes more sense to me.
gora_mohanty 4mo ago
Heh! Are you me? Echo your comments: Mercurial seemed more logical, and had one way of doing things. Have gone over to git, but still need to search for the command that I need.
ezst 4mo ago
Then you made the right choice, and it's only unfortunate that not enough of you made the same to tip the scales in favour of mercurial, or at least to avoid the monopolistic situation we are in now. I might say that I stopped thinking too hard about this many years ago: now I use hg-git whenever I must interact with git, but do regret that the more sophisticated/qol features of hg (branches, evolve, phases, topics, ...) don't exist in git, and that's the real bummer: the more limiting alternative won, then stagnated, and we are all worse off as a result.

avarun 4mo ago

Around 20 years ago Facebook made the same choice, so you're in good company in terms of technically sophisticated shops.

loeg 4mo 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 4mo ago
  You can use all the normal hg commands at Meta. It’s a regular mercurial repo from the standpoint of a user
  - loeg 4mo ago
    Yeah, but people using open source mercurial aren't in the same boat. It's a different codebase.
zeroonetwothree 4mo ago
Facebook didn’t adopt mercurial until something like 2014? And before that used svn -> git

woadwarrior01 4mo 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.

tempest_ 4mo ago

Our company also made this choice. One of the first things I did was switch us to git. Mercurial was way easier to use and fit our use case but all the tooling was built for git.

amluto 4mo ago

I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. But it was not all amazing: Mercurial’s branching model was very poor, and its sequentially numbered revision system was and remains a very bad design.

locknitpicker 4mo ago
> I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches, of even we could perhaps install a module such as shelve. That was the image that Mercurial left with me with regards to git: missing critical features and not bothering to bridge the gap.
- marcher 4mo ago
  It did have a kind of equivalent to stashes in the mq extension, but its interface was a bit esoteric compared to the rest of Hg, from what I remember.
  - voidnap 4mo ago
    A lot of features that git had by default had to be enabled as plugins in mercurial. The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off. I think some of the extensions were very basic stuff like graph logging and colorized output -- and mq like you said. So it was kind of unfortunate that people got a bad impression of hg from that and bounced off.
    - locknitpicker 4mo ago
      > The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off. It goes a little deeper than that. Prospective Mercurial users who wanted a specific feature were first greeted with claims that they were in the wrong for even entertaining the idea they needed such a thing. The rationale was that Mercurial already did everything they could possibly wanted to do, and so by definition wanting to do something differently was proof the user was in the wrong. But to stop hearing about how feature X or Y was needed, they could roll out their own extension and leave the project alone and not bother them with these silly things. Shipping extensions by default is an absurdity, once you think about it. It's effectively a way to disable features by default and stop hearing about how the project needs to support a feature. And that's how Mercurial dealt with it's potential user base.

justsomehnguy 4mo ago

You did the right at the right time, you wasn't some prescient being. Why are you

3form 4mo ago

I'm glad that I stuck to git for a similar reason; it won the war. And I understand the need for simpler tools. But to offer a point I haven't heard from anyone before: at least I feel that I am done with it, I learned this tool sufficiently and I can move on with my life. From time to time I add something to my git toolbelt. I feel if Mercurial or anything else have won, I would maybe have to learn another tool in 5 years, whatever else got popular, and another in next 5 years. But now I have everything I need in git, and always have needed. I hold some hope in it that perhaps the learning curve was worth it.

MBCook 4mo ago
That’s a great point I hadn’t thought of before. I’m glad there is one clear winner and we’re not in the common position of having 2-3 relevant/semi-relevant choices that you’re frequently asked to switch between depending on which project you’re looking at at the moment. Git is modern version control, whatever you think of it, and there’s a simplicity to that.
esafak 4mo ago
Despite not using anything else, I don't know all the git commands I need to get my job done so I use UIs and my agent. It's just not intuitive enough, some things are just not possible to do right, and I look forward to ditching it.
- pif 4mo ago
  > some things are just not possible to do right If git doesn't let you do them "right", your concept if "right" is wrong.

qwery 4mo ago

I don't think Git winning a popularity contest is a reason for choosing Mercurial to have been wrong, or unfortunate. Was there some negative consequence from the decision -- either directly from Mercurial itself, or just because over time everyone expected Git, perhaps? (Hopefully this comes across as curious, which it is, and not antagonistic, which its not)

MBCook 4mo ago
Not GP but there is a consequence. These days if someone has used version control they almost certainly know Git. That means pretty much everyone who comes in the door needs Mercurial training, whether formal or informal. You’d get the same effect from still using CVS, SVN, or other things. That may not be a big issue. If someone understands version control I’d hope they could adapt to another minder pretty fast. It’s still an issue. There is technically a cost.
- gmueckl 4mo ago
  There is an initial cost to learning hg, but it is usually offset by the less destructive nature of hg's behaviors and defaults in the long term.

yegle 4mo ago

I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects, and that is changing given the sad state of GitHub. Another contender is Jujutsu (jj) which allows you to use jj as frontend and use Git as the backend (with the potential to support any backend, e.g. Google's proprietary Piper), with the best ergonomic and the widest availability of hosting solutions.

ncphillips 4mo ago
I’ve recently switched to jj and it is truly amazing. It too about a week for me to “get it”. The tool is amazing but I think there’s way too much emphasis on what it does/allows rather than what benefits it brings to your workflow. If they get that marketing right I could see it growing. If not, I’ll keep using it
- j_bum 4mo ago
  Would you be willing to pitch why you like jj and find it useful? How were you using git? I use git mostly on single-dev projects, with branched development patterns. Would someone like me with a simple git use-case find JJ enjoyable?
  - kaeshiwaza 4mo ago
    jj is amazing, even as a solo dev on small projects. It's difficult to explain because it depends of each usage, but it's very easy and safe (you can undo everything) to just try and see.
lmm 4mo ago
> I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects Nah. At the time BitBucket was the better way to do open source projects, and they were Mercurial-first. But eventually they had to add Git support because there was so much demand.

jjav 4mo ago

Mercurial is one of the many sad stories of far better technology being forgotten by the popularity contest juggernaut of something else. I still use mercurial for all my personal project where I don't need to care what anyone else thinks. It is pleasant to use good tools, just like I like to buy top quality rachets or such.

loeg 4mo ago
Mercurial wasn't the better technology, though. The UX is almost the same as git, diverging in ways that are arguably worse, but the tools were written in much slower Python (initially, and for many years after).
- dijit 4mo ago
  Writing your tooling in python is valid while starting out and prototyping. One of the big criticisms I've seen levied against Rust is that refactoring is extremely difficult, so prototyping on ideas in the language itself is a poor experience. I've personally had great success using python, then gradually rewriting the tool I have with py03 to "oxidise" the program iteratively. Starting with C was great for performance of Git, but damn if it's not a terrible UX these days, I can believe that the choice of toolchain and language was a contributor to that fact.
  - IshKebab 4mo ago
    > Writing your tooling in python is valid while starting out and prototyping. This fallacy again. Tell me, when did Mercurial decide "ok the prototype is done, we'll rewrite it in a proper language"? They didn't, of course. Because nobody ever does. Your "prototype" gradually becomes a 100k line product that you can't afford to rewrite. (I guess you can YOLO it with AI these days but that wasn't an option for Mercurial.) > Starting with C was great for performance of Git, but damn if it's not a terrible UX these days Git's terrible UX doesn't have anything to do with C. C doesn't make you always pick a different flag for "delete".
    - deleted 4mo ago

fHr 4mo ago

meanwhile my org still uses svn for a lot of repos at least my teams are full git...ugh

martin-t 4mo ago

I hate that social factors like popularity are a thing in technical decisions. I have not used mercurial (though heard good things about it) but I saw a similar thing play out in Rust gamedev. There are 2 competing game engines, one better technically, the other much more popular. Now, if everyone made a purely technical decision, they'd pick the first one and eventually it would become the more popular one. Unfortunately, whenever I asked people why they chose the second one, they said because it was more popular. Tragedy of the commons. If it's any consolation, maybe jj will take over. I haven't tried it yet (I use the staging area a lot in my workflow), but AFAIK they made the choice to be git-compatible which means it's not a choice between one or the other but lets people and teams migrate gradually.

Shish2k 4mo ago
FWIW you can still have a staging-area-like workflow with JJ - it's just that while git has "commits", "the staging area", "the working directory", and "stashes" as four separate concepts with four separate toolkits, in JJ all of those things are "commits" and a single toolkit works with all of them :)
- martin-t 4mo ago
  I hoped that would be possible but wasn't sure, thanks.
HWR_14 4mo ago
> Tragedy of the commons That's a different concept. You are describing network effects.

foresto 4mo ago

> I helped them make the wrong choice, Mercurial. 20 years ago, Mercurial was not the wrong choice. - Its internal design was very similar to Git's. - Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.) - Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model. - (It had a third major advantage over Git that I unfortunately cannot recall at the moment.) So you weren't wrong back then... ...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.

ciupicri 4mo ago
I don't know what you mean by ergonomics, but I remember trying both Mercurial and Git back in the days after using Subversion before. I didn't like how Mercurial didn't easily let me rewrite history and do stuff like `git commit --ammend` or `git rebase`. Mercurial users kept telling me using an extension to manage patches on top of Mercurial (I think it was quilt). I agree about the Windows support. hg serve was also nice. Plus TortoiseHg.
- thfuran 4mo ago
  Mercurial does let you amend commits like git does, histedit is essentially identical to rebase -i, and evolve is better than anything git has.
  - ciupicri 4mo ago
    Isn't histedit [1] an extension? I don't think it was available back then, or if I tried I didn't like it. I don't remember evolve [2] at all. [1]: https://repo.mercurial-scm.org/hg/help/histedit https://repo.mercurial-scm.org/hg/help/histedit [2]: https://repo.mercurial-scm.org/hello/help/evolve https://repo.mercurial-scm.org/hello/help/evolve

dismalaf 4mo ago

I used Mercurial back in the day too. I agree, it was better. That being said, GitHub was better than other similar services which no doubt helped git win and now, git is ubiquitous.

sampo 4mo ago

> But I guess I couldn't read the future in terms of which one would win out! After Linus Torvalds gave this talk at Google in 2007, it was clear he would win. (Is there a better quality video somewhere?) https://www.youtube.com/watch?v=idLyobOhtO4 https://www.youtube.com/watch?v=idLyobOhtO4 But I agree: Mercurial was definitely friendlier for people who didn't have time time to go through the technicalities of git. To use git smoothly you pretty much need to learn how it works internally.

PunchyHamster 4mo ago
To be entirely fair nothing in git backend prevents someone to make friendlier frontend.
- gabrielhidasy 4mo ago
  Case in point is Magit, I use Mercurial almost every day at work so git got a bit unfamiliar, but Magit is still more natural then mercurial for me.

squirrellous 4mo ago

Both Facebook and Google internally use a custom version of mercurial, so I wouldn’t count it out just yet.

vogelke 4mo ago

Best part about open source -- Mercurial is still around, I use it for my home servers, and it's being maintained. I can use git, but Mercurial's workflow just makes more sense to me.

gora_mohanty 4mo ago

Heh! Are you me? Echo your comments: Mercurial seemed more logical, and had one way of doing things. Have gone over to git, but still need to search for the command that I need.

ezst 4mo ago

Then you made the right choice, and it's only unfortunate that not enough of you made the same to tip the scales in favour of mercurial, or at least to avoid the monopolistic situation we are in now. I might say that I stopped thinking too hard about this many years ago: now I use hg-git whenever I must interact with git, but do regret that the more sophisticated/qol features of hg (branches, evolve, phases, topics, ...) don't exist in git, and that's the real bummer: the more limiting alternative won, then stagnated, and we are all worse off as a result.