5 ms·

I would be interested in hearing from people who are using hg still. What is the reasoning? Do you see something in hg that the rest of us don't? Are there spec

I would be interested in hearing from people who are using hg still. What is the reasoning? Do you see something in hg that the rest of us don't? Are there specific features of hg that git doesn't have?

isxek 13y ago
Speaking for myself: the one specific thing I use every now and then in Mercurial is "hg serve" command. It allows me to serve up my changes to others in an ad-hoc way without needing to set up a repo in the usual places (Bitbucket, Github, etc.). If one needs to set up a local repo hosting service for internal use in a .NET company, there's SCM Manager (http://www.scm-manager.org/ http://www.scm-manager.org/), which is free, supports both Hg and Git, and (IMO) pretty easy to put up on a Windows server. I have not tried others that use purely Git, though, and I've never tried setting SCM Manager up on a Linux server. Personally, I have no problem if the whole team decides to use Git instead of what we're using now (TFS), but most of them, if not all, avoid the CLI like a plague. Even with excellent GUI frontends like Git Extensions and SourceTree.
- yapcguy 13y ago
  SourceTree seems to get slower and slowerespecially if you have submodules and lots of branches. Not sure why. Any good alternatives out there?
  - isxek 13y ago
    If you're using just Git, have you tried Git Extensions (https://code.google.com/p/gitextensions/ https://code.google.com/p/gitextensions/)? We don't use any submodules where I work, so I've never tried it with that.
- the_mitsuhiko 13y ago
  > Speaking for myself: the one specific thing I use every now and then in Mercurial is "hg serve" command. It allows me to serve up my changes to others in an ad-hoc way without needing to set up a repo in the usual places (Bitbucket, Github, etc.). You can do the same in git: git daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/ or git daemon --verbose --export-all --base-path=. --reuseaddr .
  - mahmoudhossam 13y ago
    Or you can use git instaweb instead?
    - lttlrck 13y ago
      Or SSH
  - isxek 13y ago
    AFAIK, this does not work with Git in Windows. I will try it at home where I have Lubuntu and see. (If it works, I'll make an alias for it.) Thanks.
- anton_gogolev 13y ago
  > If one needs to set up a local repo hosting service for internal use in a .NET company, There's also (shameless plug follows) HgLab ( http://hglabhq.com/ http://hglabhq.com/ ).
  - isxek 13y ago
    I was supposed to try this out after SCM Manager, but our IT admin has not replaced the server I was using after it broke. If I ever get access to one again, I'll try it.
meritt 13y ago
We use hg because bitbucket.org offered free private repos (no git back then) and it completely meets our needs. I'm also not familiar enough with git to know what benefits it provides over mercurial.
erichurkman 13y ago
Mozilla does. It's been discussed numerous times on mozilla.dev mailing lists [1], with a lot of great discussion about it. [1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/k1MW06xRYPo https://groups.google.com/forum/#!topic/mozilla.dev.platform...
- clarkevans 13y ago
  Facebook does as well. https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
nilved 13y ago
Mercurial isn't the terrible DVCS that people left for greener git pastures; indeed it's the opposite: GitHub is why git won, and people are still learning how terrible git is and how awesome Mercurial is. They don't "still use" Mercurial, they "still use" git. Mercurial has a great API. git has a terrible API. Mercurial is a joy to extend in Python. git is impossible to extend to any meaningful degree and is a terrible mess of Perl, shell script and C. git is a hack and Mercurial is the future.
- yapcguy 13y ago
  I use both. I dont think Git 'won' but it is more popular. I suspect many git users dont even know why they use git except because they were told to, they probably never tried hg or know anything about darcs, bitkeeper, etc.
  - leobelle 13y ago
    I like git because it stores objects, not diffs and you can recover from almost anything with reflog.
    - anton_gogolev 13y ago
      > I like git because it stores objects, not diffs Now _that's_ a reason to pick a VCS! Would you drop Git if you found out that this is not true [1]? [1]: http://git-scm.com/book/en/Git-Internals-Packfiles http://git-scm.com/book/en/Git-Internals-Packfiles
      - tomlu 13y ago
        I see where he is coming from even if the wording is ambiguous. Git presents the abstraction of storing objects, and diffs are inferred. The exact implementation is beside the point.
        tonfa 13y ago
        But then mercurial is the same, the abstraction is about file content, the diff compression is an internal detail of the storage format like packs.
reactor 13y ago
I've been using both Git and Hg for different projects and found with recent releases (2.6 onwards) mercurial getting quite fast. I think hg commands are more sane and exposes only what it's required by users. Also there isn't anything you can do with hg but can't do with git and vice versa, if you look closely. These are just the tools that must help you get going, so if you/co-workers are comfortable with git, there is no reason to switch to hg. (and from hg to git as well). They both have pros and cons so we will never find THE BEST dvcs. Don't bother too much (they both are super capable) rather focus on problems that need more attention.
toggle 13y ago
For me, it's: 1. The queues extension. 2. A bazillion other extensions. 3. The source code is pretty reasonable -- even mortal humans can contribute and write their own extensions. I've found the queues extension to be really useful. It's like having multiple staging areas, which will later become multiple commits. I tend to change too many things, and then remember that I need to create specific commits. Queues makes that possible. I haven't found a good way of doing that in git, although I still use git every day without any big problems.
- Skinney 13y ago
  git stash? Actually, you can also just create a branch, commit your work (instead of hg qpush) and just use git rebase --interactive when you want to "finalize" your work.
  - jordigh 13y ago
    The exact same workflow works pretty much the same way in hg, with shelve (stash) and histedit (rebase -i). There is even a better way nowadays with hg evolve, but it's still beta.
    - Skinney 13y ago
      Hows the backup story with Hg nowadays? Git uses an immutable storage solution, so rebasing or other commands to alter history doesn't delete anything. Hg doesn't have the same architecture, so how does undoing histedit work? Genuinly interested, not trying to start a flamewar.
mamcx 13y ago
I consider hg far more easy to use than git, specially for the most used commands (status, fetch, push). I need to check the docs about how do the damm push each time with github. My only gripe with mercurial? That everyone else asume git.
- Skinney 13y ago
  check the docs? What is so hard to remember about "git push"?
  - jordigh 13y ago
    This: jordi@Iris:~$ git help push | wc -l 544 jordi@Iris:~$ hg help push | wc -l 50
    - Skinney 13y ago
      This is due to Git's tight integration with regards to branches and namespaced branches though isn't it? Hg push isn't aware of bookmarks as far as I know, so Git has more to explain compared to Hg, where lightweight branches are a plugin. Or am I wrong on this?
      - jordigh 13y ago
        Wow. I use Mercurial so much, that I forget that some people have no idea about it at all. No, hg bookmarks are not a plugin, although they were like four years ago. Hg push has this to say about bookmarks: If -B/--bookmark is used, the specified bookmarked revision, its ancestors, and the bookmark will be pushed to the remote repository. That's all it has to say. If you do "hg help bookmarks", you'll get more options about bookmarks, but they're not immediately relevant to pushing.
        Skinney 13y ago
        It is still a plugin, it's just bundled/installed by default. I've worked with Mercurial for the better part of a year, I'm not clueless about it. But yeah, since branches/bookmarks are an integral part of how you work with Git, you also have more options regarding branches/bookmarks in several git commands. Git allows you to push a local branch to a remote branch of a different name. This is helpfull when you're pushing to different remotes, and the some of the local branches should map to master on different remotes. But this of course requires more information to stand in git pull's documentation. There are, of course, other features as well. Just because git push has some 'advanced' featues, doesn't make the actual push command difficult to understand though. Most of the time you just use 'git push', same as Mercurial, git just allows you to do more with git push than what Mercurial allows you to.
grey413 13y ago
Four reasons, all dating back to when I started using VC. 1) The GUIs were better, especially on windows. I think that gap has closed some in the last few years, but I think hg still has an edge. 2) Bitbucket offered free private repos and was hg only when they started out 3) The command line semantics were less imposing 4) I happened to find some really good introductory literature for hg. I was a very, very green developer at the time so all of these points mattered a lot.
dscrd 13y ago
I got used to how hg works and now, in comparison, git always confuses the hell out of me with its unintuitive commands and odd walls-of-text errors.
benrhughes 13y ago
At work we have non-devs (mostly scientists) using our repos, and I didn't want to have to teach them git. Mercurial is much easier to pick up IME. With the right plugins enabled, there's not much I miss day to day compared with git. At home I still use git. In part because of github, in part because I like some of the default behaviour better, and in part because being forced to learn how it works to dig my way out of holes broadens my understanding of DVCSs in general.
imakesnowflakes 13y ago
Mercurial gives you complete DAG of history with enough tools (revsets) to filter and view it in any way. Git lets you peep into the DAG of history through small windows, called 'branches'. This was the biggest annoyance for me when I tried git. You cannot even ask git for the id of the currently checked out revision, ie if you are not on a branch tip. And yes, the inconsistent cli is a big turnoff too.

isxek 13y ago

Speaking for myself: the one specific thing I use every now and then in Mercurial is "hg serve" command. It allows me to serve up my changes to others in an ad-hoc way without needing to set up a repo in the usual places (Bitbucket, Github, etc.). If one needs to set up a local repo hosting service for internal use in a .NET company, there's SCM Manager (http://www.scm-manager.org/ http://www.scm-manager.org/), which is free, supports both Hg and Git, and (IMO) pretty easy to put up on a Windows server. I have not tried others that use purely Git, though, and I've never tried setting SCM Manager up on a Linux server. Personally, I have no problem if the whole team decides to use Git instead of what we're using now (TFS), but most of them, if not all, avoid the CLI like a plague. Even with excellent GUI frontends like Git Extensions and SourceTree.

yapcguy 13y ago
SourceTree seems to get slower and slowerespecially if you have submodules and lots of branches. Not sure why. Any good alternatives out there?
- isxek 13y ago
  If you're using just Git, have you tried Git Extensions (https://code.google.com/p/gitextensions/ https://code.google.com/p/gitextensions/)? We don't use any submodules where I work, so I've never tried it with that.
the_mitsuhiko 13y ago
> Speaking for myself: the one specific thing I use every now and then in Mercurial is "hg serve" command. It allows me to serve up my changes to others in an ad-hoc way without needing to set up a repo in the usual places (Bitbucket, Github, etc.). You can do the same in git: git daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/ or git daemon --verbose --export-all --base-path=. --reuseaddr .
- mahmoudhossam 13y ago
  Or you can use git instaweb instead?
  - lttlrck 13y ago
    Or SSH
- isxek 13y ago
  AFAIK, this does not work with Git in Windows. I will try it at home where I have Lubuntu and see. (If it works, I'll make an alias for it.) Thanks.
anton_gogolev 13y ago
> If one needs to set up a local repo hosting service for internal use in a .NET company, There's also (shameless plug follows) HgLab ( http://hglabhq.com/ http://hglabhq.com/ ).
- isxek 13y ago
  I was supposed to try this out after SCM Manager, but our IT admin has not replaced the server I was using after it broke. If I ever get access to one again, I'll try it.

meritt 13y ago

We use hg because bitbucket.org offered free private repos (no git back then) and it completely meets our needs. I'm also not familiar enough with git to know what benefits it provides over mercurial.

erichurkman 13y ago

Mozilla does. It's been discussed numerous times on mozilla.dev mailing lists [1], with a lot of great discussion about it. [1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/k1MW06xRYPo https://groups.google.com/forum/#!topic/mozilla.dev.platform...

clarkevans 13y ago
Facebook does as well. https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...

nilved 13y ago

Mercurial isn't the terrible DVCS that people left for greener git pastures; indeed it's the opposite: GitHub is why git won, and people are still learning how terrible git is and how awesome Mercurial is. They don't "still use" Mercurial, they "still use" git. Mercurial has a great API. git has a terrible API. Mercurial is a joy to extend in Python. git is impossible to extend to any meaningful degree and is a terrible mess of Perl, shell script and C. git is a hack and Mercurial is the future.

yapcguy 13y ago
I use both. I dont think Git 'won' but it is more popular. I suspect many git users dont even know why they use git except because they were told to, they probably never tried hg or know anything about darcs, bitkeeper, etc.
- leobelle 13y ago
  I like git because it stores objects, not diffs and you can recover from almost anything with reflog.
  - anton_gogolev 13y ago
    > I like git because it stores objects, not diffs Now _that's_ a reason to pick a VCS! Would you drop Git if you found out that this is not true [1]? [1]: http://git-scm.com/book/en/Git-Internals-Packfiles http://git-scm.com/book/en/Git-Internals-Packfiles
    - tomlu 13y ago
      I see where he is coming from even if the wording is ambiguous. Git presents the abstraction of storing objects, and diffs are inferred. The exact implementation is beside the point.
      - tonfa 13y ago
        But then mercurial is the same, the abstraction is about file content, the diff compression is an internal detail of the storage format like packs.

reactor 13y ago

I've been using both Git and Hg for different projects and found with recent releases (2.6 onwards) mercurial getting quite fast. I think hg commands are more sane and exposes only what it's required by users. Also there isn't anything you can do with hg but can't do with git and vice versa, if you look closely. These are just the tools that must help you get going, so if you/co-workers are comfortable with git, there is no reason to switch to hg. (and from hg to git as well). They both have pros and cons so we will never find THE BEST dvcs. Don't bother too much (they both are super capable) rather focus on problems that need more attention.

toggle 13y ago

For me, it's: 1. The queues extension. 2. A bazillion other extensions. 3. The source code is pretty reasonable -- even mortal humans can contribute and write their own extensions. I've found the queues extension to be really useful. It's like having multiple staging areas, which will later become multiple commits. I tend to change too many things, and then remember that I need to create specific commits. Queues makes that possible. I haven't found a good way of doing that in git, although I still use git every day without any big problems.

Skinney 13y ago
git stash? Actually, you can also just create a branch, commit your work (instead of hg qpush) and just use git rebase --interactive when you want to "finalize" your work.
- jordigh 13y ago
  The exact same workflow works pretty much the same way in hg, with shelve (stash) and histedit (rebase -i). There is even a better way nowadays with hg evolve, but it's still beta.
  - Skinney 13y ago
    Hows the backup story with Hg nowadays? Git uses an immutable storage solution, so rebasing or other commands to alter history doesn't delete anything. Hg doesn't have the same architecture, so how does undoing histedit work? Genuinly interested, not trying to start a flamewar.

mamcx 13y ago

I consider hg far more easy to use than git, specially for the most used commands (status, fetch, push). I need to check the docs about how do the damm push each time with github. My only gripe with mercurial? That everyone else asume git.

Skinney 13y ago
check the docs? What is so hard to remember about "git push"?
- jordigh 13y ago
  This: jordi@Iris:~$ git help push | wc -l 544 jordi@Iris:~$ hg help push | wc -l 50
  - Skinney 13y ago
    This is due to Git's tight integration with regards to branches and namespaced branches though isn't it? Hg push isn't aware of bookmarks as far as I know, so Git has more to explain compared to Hg, where lightweight branches are a plugin. Or am I wrong on this?
    - jordigh 13y ago
      Wow. I use Mercurial so much, that I forget that some people have no idea about it at all. No, hg bookmarks are not a plugin, although they were like four years ago. Hg push has this to say about bookmarks: If -B/--bookmark is used, the specified bookmarked revision, its ancestors, and the bookmark will be pushed to the remote repository. That's all it has to say. If you do "hg help bookmarks", you'll get more options about bookmarks, but they're not immediately relevant to pushing.
      - Skinney 13y ago
        It is still a plugin, it's just bundled/installed by default. I've worked with Mercurial for the better part of a year, I'm not clueless about it. But yeah, since branches/bookmarks are an integral part of how you work with Git, you also have more options regarding branches/bookmarks in several git commands. Git allows you to push a local branch to a remote branch of a different name. This is helpfull when you're pushing to different remotes, and the some of the local branches should map to master on different remotes. But this of course requires more information to stand in git pull's documentation. There are, of course, other features as well. Just because git push has some 'advanced' featues, doesn't make the actual push command difficult to understand though. Most of the time you just use 'git push', same as Mercurial, git just allows you to do more with git push than what Mercurial allows you to.

grey413 13y ago

Four reasons, all dating back to when I started using VC. 1) The GUIs were better, especially on windows. I think that gap has closed some in the last few years, but I think hg still has an edge. 2) Bitbucket offered free private repos and was hg only when they started out 3) The command line semantics were less imposing 4) I happened to find some really good introductory literature for hg. I was a very, very green developer at the time so all of these points mattered a lot.

dscrd 13y ago

I got used to how hg works and now, in comparison, git always confuses the hell out of me with its unintuitive commands and odd walls-of-text errors.

benrhughes 13y ago

At work we have non-devs (mostly scientists) using our repos, and I didn't want to have to teach them git. Mercurial is much easier to pick up IME. With the right plugins enabled, there's not much I miss day to day compared with git. At home I still use git. In part because of github, in part because I like some of the default behaviour better, and in part because being forced to learn how it works to dig my way out of holes broadens my understanding of DVCSs in general.

imakesnowflakes 13y ago

Mercurial gives you complete DAG of history with enough tools (revsets) to filter and view it in any way. Git lets you peep into the DAG of history through small windows, called 'branches'. This was the biggest annoyance for me when I tried git. You cannot even ask git for the id of the currently checked out revision, ie if you are not on a branch tip. And yes, the inconsistent cli is a big turnoff too.