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?
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.
Now _that's_ a reason to pick a VCS! Would you drop Git if you found out that this is not true [1]?
I was thinking of SVN which does store its commits as diffs, which makes it brittle (anyone that has tried to use the svn admin tools to rewrite the repository will know what I mean).
A larger user base and a large number of companies using it mean that there will be more investment in the tool. So there is a variety of companies that invest in it. There is a smaller chance development will stop on Git compared to HG. So basically the Emacs team concluded they don't want to be stuck with another BZR, and Git seems like a safer choice.
A variety of companies have bet on HG, but decided they needed to support Git along side it to get more sales (Fog Creek and Atlassian).
I feel like Github was the deciding tech that made Git the more popular code. There are a number of other companies supporting HG still, so it won't go away anytime soon, but it's hard to say if it'll be here as long as Git.
[0] http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg000...
You have tools like Kiln Harmony[0] that lets you use git/mercurial for the same repo (looks like it cross-commit between the 2).
Git gives you all commands all at once, while Mercurial gives you just the functionality needed 90% of the time that can't really get you in trouble. Mercurial ships officially supported extensions with Mercurial that let you do history rewriting and other fun stuff that people are used to with git rebase.
I'm more a fan of Mercurial's CLI syntax/terminology, but Git has really won the popularity contest at this point. If you ever have questions about Git usage, the question has probably already been asked and has a lot more people that know and enjoy it.
Mercurial does have some advantages going for it still I believe. Being purely written in python makes it work a bit better on Windows. And as Facebook has said, it is easier to develop new plugins for Mercurial (at least given their skillset). I also like the Mercurial Largefile extension (if you have to deal with a lot of binary data). I know there are 3rd party modules like git-annex, but nothing officially part of Git.
[0] http://blog.fogcreek.com/kiln-harmony-internals-the-basics/
For everybody who does not like git there is one who does. I vastly prefer git over hg after having used hg for a few years and I did not regret switching a single bit.
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/), 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.
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 .
There's also (shameless plug follows) HgLab ( http://hglabhq.com/ ).
[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform...
https://code.facebook.com/posts/218678814984400/scaling-merc...
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.
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.
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.
I'm also not familiar enough with git to know what benefits it provides over mercurial.
My only gripe with mercurial? That everyone else asume git.
jordi@Iris:~$ git help push | wc -l
544
jordi@Iris:~$ hg help push | wc -l
50No, 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.
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.
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.
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.