9 ms·

Can someone enlighten me as to the advantage of sticking with Mercurial? I've tried hg many times and personally found nothing compelling about it compared to g

by BluSyn 6y ago

Can someone enlighten me as to the advantage of sticking with Mercurial? I've tried hg many times and personally found nothing compelling about it compared to git workflows. Git is ubiquitous, there's no really important feature set that hg offers over git, and it's super trivial to convert repos from hg -> git. So why go through this effort? Note: I'm not trying to start a flamewar; genuinely curious.

ma2rten 6y ago
Mercurial is much more user friendly. Also big companies such as Facebook and Google use it because it's more extensible.
- klodolph 6y ago
  Facebook and Google may use it but it serves, more or less, as a front-end to something else. Especially at Google, where it is optional to use Mercurial at all.
bachmeier 6y ago
There's no reason not to use Mercurial. It's version control software. If you like it, use it. It's that simple.
- mekster 6y ago
  Yeah but I like Gitea and it doesn't support Mercurial. How can I just use it?
- sjellis 6y ago
  Version control is one of those things where a lot of the value comes from using what other people use. By definition, version control is for collaboration, so using a less well-known version control system impedes the regular work of your project. There's also the issue that version control is integrated into lots of other software. Everything now supports Git and Subversion, but support for other VCSes is rarer. This is kind of unfortunate, because it makes innovation hard. Projects like pijul exist to try to move the state of the art forward, but it's difficult to see how they will gain adoption.
johnwalkr 6y ago
I find it more intuitive than git. I think it's especially easier to move, split or combine repos, but others will disagree. We used to use it at my company, but at a certain point, it had to be a forced effort to use as opposed to git, which is the default for most tools and incoming engineers. Now that bitbucket support is gone, I agree it's not worth the effort unless it's already deeply integrated into your tools.
tdeck 6y ago
iIUC Mercurial is better for managing very large repos because it supports partial checkout. This large companies with monorepos are more likely to choose mercurial. Of course there are ways to modularize a large codebase in Git (submodules, Android's repo system) but they tend to be clunky and inconvenient.
- johnwalkr 6y ago
  I haven't used it in a while and forgot about that very nice feature!
- tdeck 6y ago
  Wow the number of typos in this comment. I shouldn't type on a broken screen.
cmehdy 6y ago
Mercurial is great at an org with lots of junior devs, because people really have to try hard to mess things up compared to git. It's very bad if you want to attract people who feel comfortable with git alone (despite the fact that they'd do quite OK with hg), and it's especially bad if you are trying to fit with very standard types of CI, which for the most part have close to no support for mercurial at one point or another in the chain. And you might find that out a bit late into the process and end up paying a steep price ("Hello Gitlab? yeah I'm gonna have to set up a local secured Jenkins instance to do this and that before sending you the rest" type of thing) Recent-ish stackoverflow survey (2-3 years ago) also indicated that hg is used even less than zip files amongst devs, and significantly less than git, so market adoption is a big hurdle and anybody joining you will have to deal with this-thing-they-probably-don't-know and tooling that might not handle it (e.g. Xcode). However I think there's value in hg being training-wheels for git and a safe haven for a bunch of newbie devs, and we're talking about people who know and enjoy tech here so using any kind of vcs will at the very least enable your team to open up to more stuff. There's plenty of tooling and support to migrate to git if/when necessary, and IMHO Mercurial gets a much worse rep than it actually deserves.
- nonbirithm 6y ago
  As someone who only knows Git, needing to work on an open source project where you had no choice but to use Mercurial was a massive pain. I don't remember what happened exactly but coming from Git I managed to accidentally make a change somewhere but later needed to pull the latest changes and couldn't figure out the equivalent of rebasing and, when I got fed up with that, hard resetting for an hour. In the end I gave up and used git-hg to fork the repository, losing the ability to merge upstream, because I wanted to get things done and did not want the requirement to learn an entirely new VCS just for this one repository to hold me back. But that's coming from me, who doesn't understand how Mercurial is supposed to be used. I felt happy when BitBucket announced they were sunsetting Mercurial, because of the miserable experience I had with that one single time and the fact that it would mean that all of the repository owners who forced you to learn Mercurial to contribute to their code would have no choice but to switch their repos to Git. But because I don't know any better I guess I don't understand what was being lost fully by losing Mercurial.
altdatathrow 6y ago
I prefer mercurial over git. The workflow and branching/merge process is a whole lot more intuitive to me. Git seems to have a million commands each with a unique set of args that can do very thing things. Either way, they're both pretty similar at a high level and work great.
BeetleB 6y ago
It. Just. Works. The only people who are unhappy with Mercurial are git users. Everyone I know who is coming from something else to Mercurial never have a desire to leave it. It has a lot (most, really) of the power of Git, but no one has found a need to make an "Oh Shit Hg" site, because it's not trivial to screw up in it. Because it has a separation between simple and advanced features (many of which are disabled unless you explicitly enable them), you don't get people wasting a lot of time trying to find the ideal workflow in Mercurial. In a sense it's a bit like Perl vs Python. Perl has many ways to do the same thing. Python is more opinionated, and has preferred ways of doing things. As a result, a team of N Mercurial users will usually not have N different workflows. In my current team, there's been a lot of thrash/arguments over the workflow (rebase vs merge, squash vs not, linear vs branched history, history rewriting vs not, etc). The documentation, though, sucks. It's quite outdated.
- mekster 6y ago
  Can someone actually mention the positive side of Mercurial specifically? I'm getting bit by git so often and for those people who are barely programmers are also required to use git to commit their HTML/CSS stuff but once something doesn't work, I have to Google around and waste an hour trying to fix the repo and I'm all for willing to use something else if it's better but I know that people just simply jumped on it because of Linux/Linus name without thinking (kernel workflows are different than most people's but people only realized after feeling the pains) and the git's ecosystem is already far ahead of the others. I even considered using subversion locally to push to central git but there is no such luck when the reverse is quite possible.
  - type0 6y ago
    > Can someone actually mention the positive side of Mercurial specifically? The workflow is faster for new users to learn, less concepts to grok, good GUI support, that's about it > and for those people who are barely programmers are also required to use git to commit their HTML/CSS stuff but once something doesn't work You would find that it's difficult to get non programmers to use hg even with a GUI, unless you have some very open minded people > I know that people just simply jumped on it because of Linux/Linus name without thinking Not true, so many git users have no idea who made this tool and don't actually care, all they care is that it's open source and suits most of their tasks
aayjaychan 6y ago
To me as a daily Mercurial user, the biggest thing it brings is, in Git parlance, a distributed reflog. It makes sharing of mutable history much easier and safer. Mercurial has the concept of changeset evolution [1] that tracks the meta-history of changesets (commits): who re-wrote which commits at when using what command. Stored as obsolescence markers in the obstore, this meta-history is synchronised with remote repositories on pull and push. [1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution https://www.mercurial-scm.org/wiki/ChangesetEvolution Combined with a nice history rewriting UI provided by the evolve extension [2], this allows some advanced collaborative workflows that are pretty awkward in Git. [2]: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/ Suppose you developed feature x on branch [3] feature-x, and submitted it for review. At the same time, you started developing feature y that depends on feature-x on branch feature-y. When feature-x is integrated to master via a rebase, you can run `hg pull` and `hg evolve`, and Mercurial will automatically rebase feature-y on top of master. This also works when commits are edited, squashed, split, reordered, or dropped. This gives reviewers more freedom to decide what to accept, without having to worry disturbing contributors' work. [3]: Using Git parlance to simplify things. Branches meaning something else in Mercurial. Now you've also pushed feature-y. This time the reviewer wants you to change something. You changed the commits, and pushed feature-y again. Even without force push, the server will not reject the push, because it knows from the obsolescence marker that the new commits are not really new but are re-written old commits. Again, this even works when commits are rebased, squashed, split, reordered, or dropped. While there is no commitment yet, now that Mercurial is gaining the ability to operate on Git repositories, there are discussions on how to store obslog in Git's store, so maybe that's something that Git will eventually have. Another thing I like very much is that every commit in Mercurial is a standalone ref. This makes a patch-based workflow a lot simpler as you don't need the ceremony of creating and cleaning up branches. You also don't run into detached heads.

by BluSyn 6y ago

ma2rten 6y ago

Mercurial is much more user friendly. Also big companies such as Facebook and Google use it because it's more extensible.

klodolph 6y ago
Facebook and Google may use it but it serves, more or less, as a front-end to something else. Especially at Google, where it is optional to use Mercurial at all.

bachmeier 6y ago

There's no reason not to use Mercurial. It's version control software. If you like it, use it. It's that simple.

mekster 6y ago
Yeah but I like Gitea and it doesn't support Mercurial. How can I just use it?
sjellis 6y ago
Version control is one of those things where a lot of the value comes from using what other people use. By definition, version control is for collaboration, so using a less well-known version control system impedes the regular work of your project. There's also the issue that version control is integrated into lots of other software. Everything now supports Git and Subversion, but support for other VCSes is rarer. This is kind of unfortunate, because it makes innovation hard. Projects like pijul exist to try to move the state of the art forward, but it's difficult to see how they will gain adoption.

johnwalkr 6y ago

I find it more intuitive than git. I think it's especially easier to move, split or combine repos, but others will disagree. We used to use it at my company, but at a certain point, it had to be a forced effort to use as opposed to git, which is the default for most tools and incoming engineers. Now that bitbucket support is gone, I agree it's not worth the effort unless it's already deeply integrated into your tools.

tdeck 6y ago

iIUC Mercurial is better for managing very large repos because it supports partial checkout. This large companies with monorepos are more likely to choose mercurial. Of course there are ways to modularize a large codebase in Git (submodules, Android's repo system) but they tend to be clunky and inconvenient.

johnwalkr 6y ago
I haven't used it in a while and forgot about that very nice feature!
tdeck 6y ago
Wow the number of typos in this comment. I shouldn't type on a broken screen.

cmehdy 6y ago

Mercurial is great at an org with lots of junior devs, because people really have to try hard to mess things up compared to git. It's very bad if you want to attract people who feel comfortable with git alone (despite the fact that they'd do quite OK with hg), and it's especially bad if you are trying to fit with very standard types of CI, which for the most part have close to no support for mercurial at one point or another in the chain. And you might find that out a bit late into the process and end up paying a steep price ("Hello Gitlab? yeah I'm gonna have to set up a local secured Jenkins instance to do this and that before sending you the rest" type of thing) Recent-ish stackoverflow survey (2-3 years ago) also indicated that hg is used even less than zip files amongst devs, and significantly less than git, so market adoption is a big hurdle and anybody joining you will have to deal with this-thing-they-probably-don't-know and tooling that might not handle it (e.g. Xcode). However I think there's value in hg being training-wheels for git and a safe haven for a bunch of newbie devs, and we're talking about people who know and enjoy tech here so using any kind of vcs will at the very least enable your team to open up to more stuff. There's plenty of tooling and support to migrate to git if/when necessary, and IMHO Mercurial gets a much worse rep than it actually deserves.

nonbirithm 6y ago
As someone who only knows Git, needing to work on an open source project where you had no choice but to use Mercurial was a massive pain. I don't remember what happened exactly but coming from Git I managed to accidentally make a change somewhere but later needed to pull the latest changes and couldn't figure out the equivalent of rebasing and, when I got fed up with that, hard resetting for an hour. In the end I gave up and used git-hg to fork the repository, losing the ability to merge upstream, because I wanted to get things done and did not want the requirement to learn an entirely new VCS just for this one repository to hold me back. But that's coming from me, who doesn't understand how Mercurial is supposed to be used. I felt happy when BitBucket announced they were sunsetting Mercurial, because of the miserable experience I had with that one single time and the fact that it would mean that all of the repository owners who forced you to learn Mercurial to contribute to their code would have no choice but to switch their repos to Git. But because I don't know any better I guess I don't understand what was being lost fully by losing Mercurial.

altdatathrow 6y ago

I prefer mercurial over git. The workflow and branching/merge process is a whole lot more intuitive to me. Git seems to have a million commands each with a unique set of args that can do very thing things. Either way, they're both pretty similar at a high level and work great.

BeetleB 6y ago

It. Just. Works. The only people who are unhappy with Mercurial are git users. Everyone I know who is coming from something else to Mercurial never have a desire to leave it. It has a lot (most, really) of the power of Git, but no one has found a need to make an "Oh Shit Hg" site, because it's not trivial to screw up in it. Because it has a separation between simple and advanced features (many of which are disabled unless you explicitly enable them), you don't get people wasting a lot of time trying to find the ideal workflow in Mercurial. In a sense it's a bit like Perl vs Python. Perl has many ways to do the same thing. Python is more opinionated, and has preferred ways of doing things. As a result, a team of N Mercurial users will usually not have N different workflows. In my current team, there's been a lot of thrash/arguments over the workflow (rebase vs merge, squash vs not, linear vs branched history, history rewriting vs not, etc). The documentation, though, sucks. It's quite outdated.

mekster 6y ago
Can someone actually mention the positive side of Mercurial specifically? I'm getting bit by git so often and for those people who are barely programmers are also required to use git to commit their HTML/CSS stuff but once something doesn't work, I have to Google around and waste an hour trying to fix the repo and I'm all for willing to use something else if it's better but I know that people just simply jumped on it because of Linux/Linus name without thinking (kernel workflows are different than most people's but people only realized after feeling the pains) and the git's ecosystem is already far ahead of the others. I even considered using subversion locally to push to central git but there is no such luck when the reverse is quite possible.
- type0 6y ago
  > Can someone actually mention the positive side of Mercurial specifically? The workflow is faster for new users to learn, less concepts to grok, good GUI support, that's about it > and for those people who are barely programmers are also required to use git to commit their HTML/CSS stuff but once something doesn't work You would find that it's difficult to get non programmers to use hg even with a GUI, unless you have some very open minded people > I know that people just simply jumped on it because of Linux/Linus name without thinking Not true, so many git users have no idea who made this tool and don't actually care, all they care is that it's open source and suits most of their tasks

aayjaychan 6y ago

To me as a daily Mercurial user, the biggest thing it brings is, in Git parlance, a distributed reflog. It makes sharing of mutable history much easier and safer. Mercurial has the concept of changeset evolution [1] that tracks the meta-history of changesets (commits): who re-wrote which commits at when using what command. Stored as obsolescence markers in the obstore, this meta-history is synchronised with remote repositories on pull and push. [1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution https://www.mercurial-scm.org/wiki/ChangesetEvolution Combined with a nice history rewriting UI provided by the evolve extension [2], this allows some advanced collaborative workflows that are pretty awkward in Git. [2]: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/doc/evolution/ Suppose you developed feature x on branch [3] feature-x, and submitted it for review. At the same time, you started developing feature y that depends on feature-x on branch feature-y. When feature-x is integrated to master via a rebase, you can run `hg pull` and `hg evolve`, and Mercurial will automatically rebase feature-y on top of master. This also works when commits are edited, squashed, split, reordered, or dropped. This gives reviewers more freedom to decide what to accept, without having to worry disturbing contributors' work. [3]: Using Git parlance to simplify things. Branches meaning something else in Mercurial. Now you've also pushed feature-y. This time the reviewer wants you to change something. You changed the commits, and pushed feature-y again. Even without force push, the server will not reject the push, because it knows from the obsolescence marker that the new commits are not really new but are re-written old commits. Again, this even works when commits are rebased, squashed, split, reordered, or dropped. While there is no commitment yet, now that Mercurial is gaining the ability to operate on Git repositories, there are discussions on how to store obslog in Git's store, so maybe that's something that Git will eventually have. Another thing I like very much is that every commit in Mercurial is a standalone ref. This makes a patch-based workflow a lot simpler as you don't need the ceremony of creating and cleaning up branches. You also don't run into detached heads.