7 ms·

My biggest issues with hg are that hg's revision numbers aren't synchronized across instances, they are local only[1] making them kind of useless, you can't eas

My biggest issues with hg are that hg's revision numbers aren't synchronized across instances, they are local only[1] making them kind of useless, you can't easily have local branches[2], and it stores changesets instead of objects. I've ever seen a convincing argument to choose hg over git. Sure you can do a lot of things with it and I'm sure it's perfectly fine to use, but if you know git, and you like git, there's no reason to switch. What does hg have that makes it better than git that you should give up git? Popularity is what git has over hg. Someone using git will probably never have to spend anytime worrying about learning hg, but an hg user will have to become familiar with git because git is used everywhere nowadays. So my recommendation to people new to versioning systems is to pick git. I can't for the life of me understand why someone would pick hg for an open source project unless they wanted to throw learning curves and barriers at developers, or they just really really liked hg (probably because they chose it over git a long time ago). [1] http://mercurial.selenic.com/wiki/RevisionNumber http://mercurial.selenic.com/wiki/RevisionNumber [2] http://stackoverflow.com/questions/8995598/can-i-mark-a-branch-as-not-going-to-push http://stackoverflow.com/questions/8995598/can-i-mark-a-bran...

twic 13y ago
> you can't easily have local branches [2] > > http://stackoverflow.com/questions/8995598/can-i-mark-a-branch-as-not-going-to-push http://stackoverflow.com/questions/8995598/can-i-mark-a-bran... I don't get it. As a citation for your assertion that you can't easily have local branches, you link to a StackOverflow question for which the accepted answer explains how to easily have local branches. What were you trying to say with that link?
- leobelle 13y ago
  I'm not going to answer your question because I feel like what I said (not tried to say, but said) was obvious, but I will point out that things like this kinda throw a wrench into the whole "hg's UI is better than git" don't ya think?
pjmlp 13y ago
> What does hg have that makes it better than git that you should give up git? Better user experience out of the box for Windows shops. This might change with Microsoft's adoption of git for TFS, but you won't find many appraisals for git at my workplace. Many people still miss hg.
- Karunamon 13y ago
  You mean tortoiseHG? There's tortoisegit as well. And the first Windows-only proprietary client I could find supports both systems (Smartgithg: http://www.syntevo.com/smartgithg/ http://www.syntevo.com/smartgithg/)
  - pjmlp 13y ago
    No, I mean the whole experience. Mercurial being Python based has less UNIX feeling than Git on its workflow experience. Plus there are better plugins for Visual Studio integration available then for Git.
    - wmgries 13y ago
      Isn't git built into Visual Studio?
      - pjmlp 13y ago
        If you have the 2013 version.
- stephen_g 13y ago
  The place I'm currently working is (sadly) a Windows shop, and we've never had any issues using msys-git. Some of us use TortiseGit for logs, diffs, etc (we used to use TortiseSVN pretty much exclusively before we moved)
ygra 13y ago
As stated by the documentation, those numbers are purely a convenience feature for when you don't want to give the actual revision hash to a command. The latter is what you have to do in git anyway.
- twic 13y ago
  Exactly. Git has one way to refer to commits: hashes. Mercurial has two: hashes and revision numbers. If you don't like revision numbers, ignore them, and you're in exactly the same position as with Git.
alwillis 13y ago
>My biggest issues with hg are that hg's revision numbers aren't synchronized across instances, they are local only[1] making them kind of useless, you can't easily have local branches[2], and it stores changesets instead of objects. Nope. Revision numbers are just a convenience when you're working locally in a repo. Just like Git, each commit is uniquely identified using a SHA hash. No again on the local branches. Again, Mercurial is even more flexible when it comes to branching that Git is: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me....

twic 13y ago

> you can't easily have local branches [2] > > http://stackoverflow.com/questions/8995598/can-i-mark-a-branch-as-not-going-to-push http://stackoverflow.com/questions/8995598/can-i-mark-a-bran... I don't get it. As a citation for your assertion that you can't easily have local branches, you link to a StackOverflow question for which the accepted answer explains how to easily have local branches. What were you trying to say with that link?

leobelle 13y ago
I'm not going to answer your question because I feel like what I said (not tried to say, but said) was obvious, but I will point out that things like this kinda throw a wrench into the whole "hg's UI is better than git" don't ya think?

pjmlp 13y ago

> What does hg have that makes it better than git that you should give up git? Better user experience out of the box for Windows shops. This might change with Microsoft's adoption of git for TFS, but you won't find many appraisals for git at my workplace. Many people still miss hg.

Karunamon 13y ago
You mean tortoiseHG? There's tortoisegit as well. And the first Windows-only proprietary client I could find supports both systems (Smartgithg: http://www.syntevo.com/smartgithg/ http://www.syntevo.com/smartgithg/)
- pjmlp 13y ago
  No, I mean the whole experience. Mercurial being Python based has less UNIX feeling than Git on its workflow experience. Plus there are better plugins for Visual Studio integration available then for Git.
  - wmgries 13y ago
    Isn't git built into Visual Studio?
    - pjmlp 13y ago
      If you have the 2013 version.
stephen_g 13y ago
The place I'm currently working is (sadly) a Windows shop, and we've never had any issues using msys-git. Some of us use TortiseGit for logs, diffs, etc (we used to use TortiseSVN pretty much exclusively before we moved)

ygra 13y ago

As stated by the documentation, those numbers are purely a convenience feature for when you don't want to give the actual revision hash to a command. The latter is what you have to do in git anyway.

twic 13y ago
Exactly. Git has one way to refer to commits: hashes. Mercurial has two: hashes and revision numbers. If you don't like revision numbers, ignore them, and you're in exactly the same position as with Git.

alwillis 13y ago

>My biggest issues with hg are that hg's revision numbers aren't synchronized across instances, they are local only[1] making them kind of useless, you can't easily have local branches[2], and it stores changesets instead of objects. Nope. Revision numbers are just a convenience when you're working locally in a repo. Just like Git, each commit is uniquely identified using a SHA hash. No again on the local branches. Again, Mercurial is even more flexible when it comes to branching that Git is: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me....