7 ms·

Mercurial user for the past 6 or 7 years here. I cling to Mercurial despite people asking me to move some of my side projects (nothing substantial though) to gi

Mercurial user for the past 6 or 7 years here. I cling to Mercurial despite people asking me to move some of my side projects (nothing substantial though) to git and github. I refuse to do that out of principle. I think Mercurial should have taken the place of git as the widely used DVCS. And I try to be THAT change I want to see. That being said, It would be great if someone can get the hg-git plugin to work seamlessly with newer versions of Mercurial on Windows and Linux, so that I can keep using Mercurial even if a project I am involved in uses git.

LukeHoersten 11y ago
Same story here. I learned both Git and HG circa 2007 and decided HG had a more pure DVCS model. I still believe that's the case and still use HG. When I interact with GitHub I use hg-git. Long time Git users: I strongly encourage you to try Mercurial.
- DigitalJack 11y ago
  Every time I try HG, I find that to do what I want I have to get a bunch of plugins. When I use a VCS, I want to know that I'm using the same commands as everyone else, so that we are all speaking the same language. Most of the git commands I use are about as straight forward and simple as they could be. If ever I manage to screw something up, the archeology commands I end up using are obtuse, but it's rare that I need them. And I'm glad they are there when I do.
  - kyrra 11y ago
    Are they plugins that you just enable in the conf file? If so, all extensions that ship with mercurial are fully supported features. They just disable parts of the cli that can be dangerous or are less commonly used. If you are having to download 3rd party extensions, then that's a different problem.
swpalmer 11y ago
Totally agree. Mercurial really is the product that deserves the spot that Git has claimed in terms of being the defacto DVCS. It's generally easier to use, well supported, and more intuitive. The good thing is that there is still a healthy competition out there to push ease of use and features forward. I think promoting Mercurial to help it gain market share is important. You don't have to suffer through Git!
- DigitalJack 11y ago
  What a silly comment. If using git is suffering to you, then don't. You know what? I hate peas. You know what else? I don't eat them. You know why git won? HG was slow as molasses when they both showed up on the scene. That and git's branches are a dream come true. I think back then, an HG branch was a clone of the repo. I can't figure out what sort of suffering people are talking about.
  - jordigh 11y ago
    Well, we can't avoid git. Being allergic to git is like being allergic to water. There are ways around it like hg-git, but they can't really hide the git underneath. We have to use git or be computer hermits.
100k 11y ago
I was really surprised that Git "won" because I thought that Mercurial's friendlier CLI and being written in Python would give it an advantage. I think I underestimated how good it makes people feel to understand something incredibly complicated. I guess immutable history was a turn off for many people as well. This fake interview is pretty funny: "Linus: Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd." http://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and-git/ http://typicalprogrammer.com/linus-torvalds-goes-off-on-linu...
- acdha 11y ago
  The main thing I found was that Mercurial was only easier for the simplest introductory tasks, where Git has largely compensated with tons of documentation, tutorials and, later, improved command-line UI. Once you needed to do anything more complicated (e.g. working on against an upstream repo you don't have commit access to) you tended to quickly end up in documentation lacunae and semi-supported extensions which rotated in and out of favor depending on which year the guide you'd found was written. My team started using Mercurial a couple years before Git but eventually migrated over because in practice Git was less surprising and nobody had lost data using it.
- xiaomai 11y ago
  That is a clever fake interview quote, but the whole notion that hg's "easier" interface should have made it won misses the point. hg's interface is more familiar (especially since we were mostly all coming from subversion at the time). Git won because it's workflow is so much better than mercurial's. Light-weight branches are better than hg branches (I know they have bookmarks now but I don't recall if they had them back then). The index is a fantastic idea that makes writing clean commits easy (I think the comparable hg option at the time was mercurial queues which are much more cumbersome to work with imo). Rebase is functionality that hg didn't include out of the box. Being able to edit commits in git is something I greatly appreciate for fixing typos and stuff. tl;dr: the interface of mercurial may be more straightforward, but git won because it allowed people to work better.
mdaniel 11y ago
> get the hg-git plugin to work seamlessly with newer versions of Mercurial on Windows and Linux Can you elaborate and/or point to an issue tracker that describes the problems? The Windows malfunction may be more work than a reasonable person would want to bite off, but getting it to work on Linux should be feasible.
_random_ 11y ago
Wow, I am not the only one :). For closed-source projects BitBucket is a no-brainer.
- sciurus 11y ago
  Bitbucket supports both mercurial and git.
Estragon 11y ago
What are the big wins of Mercurial vs Git?
- papaf 11y ago
  I find Mercurial easier to use, even though I use git much more. I also find it harder to shoot myself in the foot with Mercurial - I've destroyed (but not lost) work with git quite a few times. Mecurial is super easy to learn - there is no reason not to be comfortable with both.
  - patrickdavey 11y ago
    I've shot myself in the foot a few times with git, however, git reflog is _often_ there to help.
    - wsc981 11y ago
      > I've shot myself in the foot a few times with git, however, git reflog is _often_ there to help. Many times this. Git reflog is an extremely powerful feature to fix mistakes. Any git user should at least in base understand what the reflog is and how it can be used for roll-backs.
- greggman 11y ago
  I don't know what the wins of hg are. Used it for a year Git has git style branches which make it really easy to work on different things. Apparently hg added some of that later but it's not the main workflow git also has a "staging area". You put things into the staging area and then commit. So for example the equivalent of "hg commit" in git is "git commit -a". The -a means "copy everything that's changed to the staging area". The advantage of the staging area is it's easy to commit just a few files even if many have changed. It's even easy to commit just a few changed lines from a file and leave the other lines un-commmited. There are other advantages I'm sure and I'm sure I didn't explain the branching one well. I can point out that I have repos with completely unrelated branches. One branch is the website, another branch is the docs, another branch is the source code, branches in hg, at least the default ones, are assumed to be something that will eventually be merged back. hg complains forever until you merge the branch back. git branches are effectively unrelated to each other, although by default git will track where it branched and if you happen to merge them where they merged. branches can be pushed and pulled to other repos or not, it's up to you. Someone above said hg has bookmarks that are similar to git branches but I'd be curious if they're actually the same.
pornel 11y ago
I've learned git first and found Mercurial hard to use. I've somehow created a branch that couldn't be deleted. Instead of being really deleted it appeared in remote repository as some kind of a "tombstone". I've tried to rebase, but to do that I had to fiddle with settings and enable plugins. My impression was that Mercurial is a higher-level version of git, with the sugary layer doing things that I don't want.
- rbehrends 11y ago
  > I've somehow created a branch that couldn't be deleted. The problem here is one of conflicting terminology. What Git calls a branch, no other version control system calls a branch. A branch in Git is really a moving pointer to the head of a branch as other VCSs would see it. The confusion can go both ways, by the way. I.e. when a user who is used to another VCS expects a branch to be a persistent label for a set of commits and then discovers that it doesn't work like that for Git repositories and that your branches may "move" or "disappear" and don't even describe sets of commits but individual commits.
  - beagle3 11y ago
    SVN tags and branches correspond quite closely to Git tags and branches, I think; "tag" is a naming of a commit, "branch" is an evolving repository that shares history (and perhaps future, if merged) with other such "branches". Except Git tracks history of the named branch in the reflog, and SVN (and others, I would guess) track it inside the repository. This is a huge difference for archeologists, but quite minor in practice from my experience.
    - tdestan 11y ago
      In SVN there really is no technical difference between a tag and a branch IIRC, although their intended usages are different, as you say.
      - mpdehaan2 11y ago
        To the point where it's almost easiest to say SVN doesn't have branches or tags - it just has directories and conventions.
reinhardt 11y ago
Similar story here. I had been using hg almost exclusively for the past 5 years, not just for personal side projects but also at work with teams using git, thanks to hg-git. Admittedly hg-git had/has its issues, especially slower push/pull performance compared to both standalone hg and git, and occasional friction with the rest team that was using git exclusively. I tried to grok git during this time and gave up more than once out of frustration. Eventually, just less than a year ago, I bit the bullet and made the switch to git. What did the trick for me was a list of short aliases I copied from somewhere, tweaked and have been maintaining in my ~/.bash_aliases ever since. Some aliases are just shortcuts for super common commands (such as "alias gts='git status'") but others remove the burden of remembering what combination of commands and arguments make sense to me ("do i undo a change with revert, reset, checkout or something else? well it depends.."). I still can't claim I know git in depth but it's good enough for day to day usage.
greggman 11y ago
Interesting. I started in hg for a year then switched to git. It took a while to get used to but once I did I never wanted to go back to hg. I've heard hg since then has added features that make it possible to have a more git like workflow but AFAICT it's still not the "recommended" at least not the default workflow which means I have no desire to switch back.

LukeHoersten 11y ago

Same story here. I learned both Git and HG circa 2007 and decided HG had a more pure DVCS model. I still believe that's the case and still use HG. When I interact with GitHub I use hg-git. Long time Git users: I strongly encourage you to try Mercurial.

DigitalJack 11y ago
Every time I try HG, I find that to do what I want I have to get a bunch of plugins. When I use a VCS, I want to know that I'm using the same commands as everyone else, so that we are all speaking the same language. Most of the git commands I use are about as straight forward and simple as they could be. If ever I manage to screw something up, the archeology commands I end up using are obtuse, but it's rare that I need them. And I'm glad they are there when I do.
- kyrra 11y ago
  Are they plugins that you just enable in the conf file? If so, all extensions that ship with mercurial are fully supported features. They just disable parts of the cli that can be dangerous or are less commonly used. If you are having to download 3rd party extensions, then that's a different problem.

swpalmer 11y ago

Totally agree. Mercurial really is the product that deserves the spot that Git has claimed in terms of being the defacto DVCS. It's generally easier to use, well supported, and more intuitive. The good thing is that there is still a healthy competition out there to push ease of use and features forward. I think promoting Mercurial to help it gain market share is important. You don't have to suffer through Git!

DigitalJack 11y ago
What a silly comment. If using git is suffering to you, then don't. You know what? I hate peas. You know what else? I don't eat them. You know why git won? HG was slow as molasses when they both showed up on the scene. That and git's branches are a dream come true. I think back then, an HG branch was a clone of the repo. I can't figure out what sort of suffering people are talking about.
- jordigh 11y ago
  Well, we can't avoid git. Being allergic to git is like being allergic to water. There are ways around it like hg-git, but they can't really hide the git underneath. We have to use git or be computer hermits.

100k 11y ago

I was really surprised that Git "won" because I thought that Mercurial's friendlier CLI and being written in Python would give it an advantage. I think I underestimated how good it makes people feel to understand something incredibly complicated. I guess immutable history was a turn off for many people as well. This fake interview is pretty funny: "Linus: Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn’t really expect anyone to use it because it’s so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd." http://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and-git/ http://typicalprogrammer.com/linus-torvalds-goes-off-on-linu...

acdha 11y ago
The main thing I found was that Mercurial was only easier for the simplest introductory tasks, where Git has largely compensated with tons of documentation, tutorials and, later, improved command-line UI. Once you needed to do anything more complicated (e.g. working on against an upstream repo you don't have commit access to) you tended to quickly end up in documentation lacunae and semi-supported extensions which rotated in and out of favor depending on which year the guide you'd found was written. My team started using Mercurial a couple years before Git but eventually migrated over because in practice Git was less surprising and nobody had lost data using it.
xiaomai 11y ago
That is a clever fake interview quote, but the whole notion that hg's "easier" interface should have made it won misses the point. hg's interface is more familiar (especially since we were mostly all coming from subversion at the time). Git won because it's workflow is so much better than mercurial's. Light-weight branches are better than hg branches (I know they have bookmarks now but I don't recall if they had them back then). The index is a fantastic idea that makes writing clean commits easy (I think the comparable hg option at the time was mercurial queues which are much more cumbersome to work with imo). Rebase is functionality that hg didn't include out of the box. Being able to edit commits in git is something I greatly appreciate for fixing typos and stuff. tl;dr: the interface of mercurial may be more straightforward, but git won because it allowed people to work better.

mdaniel 11y ago

> get the hg-git plugin to work seamlessly with newer versions of Mercurial on Windows and Linux Can you elaborate and/or point to an issue tracker that describes the problems? The Windows malfunction may be more work than a reasonable person would want to bite off, but getting it to work on Linux should be feasible.

_random_ 11y ago

Wow, I am not the only one :). For closed-source projects BitBucket is a no-brainer.

sciurus 11y ago
Bitbucket supports both mercurial and git.

Estragon 11y ago

What are the big wins of Mercurial vs Git?

papaf 11y ago
I find Mercurial easier to use, even though I use git much more. I also find it harder to shoot myself in the foot with Mercurial - I've destroyed (but not lost) work with git quite a few times. Mecurial is super easy to learn - there is no reason not to be comfortable with both.
- patrickdavey 11y ago
  I've shot myself in the foot a few times with git, however, git reflog is _often_ there to help.
  - wsc981 11y ago
    > I've shot myself in the foot a few times with git, however, git reflog is _often_ there to help. Many times this. Git reflog is an extremely powerful feature to fix mistakes. Any git user should at least in base understand what the reflog is and how it can be used for roll-backs.
greggman 11y ago
I don't know what the wins of hg are. Used it for a year Git has git style branches which make it really easy to work on different things. Apparently hg added some of that later but it's not the main workflow git also has a "staging area". You put things into the staging area and then commit. So for example the equivalent of "hg commit" in git is "git commit -a". The -a means "copy everything that's changed to the staging area". The advantage of the staging area is it's easy to commit just a few files even if many have changed. It's even easy to commit just a few changed lines from a file and leave the other lines un-commmited. There are other advantages I'm sure and I'm sure I didn't explain the branching one well. I can point out that I have repos with completely unrelated branches. One branch is the website, another branch is the docs, another branch is the source code, branches in hg, at least the default ones, are assumed to be something that will eventually be merged back. hg complains forever until you merge the branch back. git branches are effectively unrelated to each other, although by default git will track where it branched and if you happen to merge them where they merged. branches can be pushed and pulled to other repos or not, it's up to you. Someone above said hg has bookmarks that are similar to git branches but I'd be curious if they're actually the same.

pornel 11y ago

I've learned git first and found Mercurial hard to use. I've somehow created a branch that couldn't be deleted. Instead of being really deleted it appeared in remote repository as some kind of a "tombstone". I've tried to rebase, but to do that I had to fiddle with settings and enable plugins. My impression was that Mercurial is a higher-level version of git, with the sugary layer doing things that I don't want.

rbehrends 11y ago
> I've somehow created a branch that couldn't be deleted. The problem here is one of conflicting terminology. What Git calls a branch, no other version control system calls a branch. A branch in Git is really a moving pointer to the head of a branch as other VCSs would see it. The confusion can go both ways, by the way. I.e. when a user who is used to another VCS expects a branch to be a persistent label for a set of commits and then discovers that it doesn't work like that for Git repositories and that your branches may "move" or "disappear" and don't even describe sets of commits but individual commits.
- beagle3 11y ago
  SVN tags and branches correspond quite closely to Git tags and branches, I think; "tag" is a naming of a commit, "branch" is an evolving repository that shares history (and perhaps future, if merged) with other such "branches". Except Git tracks history of the named branch in the reflog, and SVN (and others, I would guess) track it inside the repository. This is a huge difference for archeologists, but quite minor in practice from my experience.
  - tdestan 11y ago
    In SVN there really is no technical difference between a tag and a branch IIRC, although their intended usages are different, as you say.
    - mpdehaan2 11y ago
      To the point where it's almost easiest to say SVN doesn't have branches or tags - it just has directories and conventions.

reinhardt 11y ago

Similar story here. I had been using hg almost exclusively for the past 5 years, not just for personal side projects but also at work with teams using git, thanks to hg-git. Admittedly hg-git had/has its issues, especially slower push/pull performance compared to both standalone hg and git, and occasional friction with the rest team that was using git exclusively. I tried to grok git during this time and gave up more than once out of frustration. Eventually, just less than a year ago, I bit the bullet and made the switch to git. What did the trick for me was a list of short aliases I copied from somewhere, tweaked and have been maintaining in my ~/.bash_aliases ever since. Some aliases are just shortcuts for super common commands (such as "alias gts='git status'") but others remove the burden of remembering what combination of commands and arguments make sense to me ("do i undo a change with revert, reset, checkout or something else? well it depends.."). I still can't claim I know git in depth but it's good enough for day to day usage.

greggman 11y ago

Interesting. I started in hg for a year then switched to git. It took a while to get used to but once I did I never wanted to go back to hg. I've heard hg since then has added features that make it possible to have a more git like workflow but AFAICT it's still not the "recommended" at least not the default workflow which means I have no desire to switch back.