不错的 GUI 工具，即使在 Windows 上也是如此（TortoiseHg 很好，非常成熟，还有其他的）
有据可查，并且即使 Windows 版本也有一个漂亮的 GUI，带有变更集的图形视图
学习曲线比 GIT 稍微容易一些 (imo)
HG 缺点：
比 git 慢一点
可能不太灵活
还有其他显着差异，但这些是我的最重要的差异头脑。老实说，如果我主要在 Windows 上工作，我可能会选择 Mercurial。
Git Pros:
Ultrafast (scales well to very large projects)
Extreme flexibility
C tools that fit in well with the Unix philosophy
Git Cons:
Steep learning curve
GUI tools exist, but (IMO) are not all that solid
HG Pros:
Very fast (though not as fast as GIT) -- Delays shouldn't be a significant problem on a project of 15-20k lines
Nice GUI tools, even on Windows (TortoiseHg is good and very mature, and there are others as well)
Well documented, and even the windows version has a nice GUI with a graphical view of changesets
Slightly easier learning curve than GIT (imo)
HG Cons:
Somewhat slower than git
Possibly a little bit less flexible
There are other significant differences, but these are the most significant in my mind. Honestly, if I were mostly working on Windows, I would go probably go with Mercurial.
多年后编辑：有一个名为 SourceTree 我对此非常满意。它支持 Git 和 Mercurial，并且可以在 App Store 上免费下载。
First, let me say I'm not a professional programmer, but an engineer who had a need for it and had to learn.
Engineer here, too. I've used Mercurial, Subversion, BitKeeper, and CVS. Haven't made it to Git yet.
I heard that hg is rather more user friendly towards windows users, regarding the user interfaces.
Not sure what was meant here, Git and Mercurial are both command-line tools at heart.
How does it handle repositories?
It's a distributed version control system (DVCS), just like Git.
Does it create them the same way as git does (just one subdirectory in a working directory) and can I just copy the whole project directory (including git repo) and just carry them somewhere with no extra thinking ? (I really liked that when I was choosing over git/svn).
Yes. Mercurial's repository lives in a .hg directory in the working directory. Also, Mercurial has a naming system in its repository to prevent filename collisions if you use it with a case-insensitive filesystem like FAT, NTFS, or HFS+.
Are there any good books on it that you can recommend (something like Pro Git, only for Hg).
What are good ways to implement hg into Visual Studio/GVim for Windows, or into Windows Explorer so I can work relatively easily (I would like to avoid using the command line for everything regarding it, like in git shell).
There's a tool called TortoiseHG. I can't attest to how good it is, since I usually just use the command-line version via Cygwin.
I've also heard git is c project, while mercurial is python ... is there any noticeable difference in speed. git was pretty speedy ... will I encounter some waiting while working.
Mercurial is pretty darn fast. I don't know about how it stacks up with Git, but it's a lot faster than Subversion.
Notice: All my projects are of let's say, middle size ... mostly numerical simulations ... 10-15000 lines (medium size?)
Sounds like my stuff. Not counting raw data, of course.
And off topic...
Most of my stuff is done in C/Fortran/Matlab and so far I've been learning git to manage it all.
I've been moving from Matlab to Python recently...
No license and maintenance crap to worry about.
It's all open source.
NumPy, SciPy, and MatPlotLib do most of what I need.
I can take my code and easily integrate it with socket-based code to talk to instrumentation. (I love being able to generate a waveform, download it to a function generator, wait for the scope to trigger, grab its trace and statistics, and put all that in a loop.)
I can integrate it with PyGtk, PyQt, a web server, a PDF generator (ReportLib), and who knows what else.
I can ship my Python-based code without having to deal with licensing or royalties.
Python is way better for disciplined software development than Matlab. Matlab's one-function-per-file and one-directory-per-class stuff is insane.
Python is easier to extend with C and C++ code. The libraries out there are better.
Just a thought.
YEARS LATER EDIT: There is a Mac DVCS tool called SourceTree which I've been very happy with. It supports both Git and Mercurial, and is available for free on the App Store.
Mercurial 有一个非常非常好的教程，由 Joel Spolsky 编写，位于 hginit.com。这是我读过的关于源代码控制的最好的教程！ :)
In terms of your points:
Mercurial is better for Windows users - easier to install, no wacky terminal corruption :) - basically more with less work, IMHO.
Git is faster than Mercurial - benchmarks show this. This is, as you said, because Git is written in C. I don't find Mercurial that slow, though, to be honest.
If your friend uses Mercurial, use Mercurial for that project. They are very similar in their basic interface and functionality - I could pick up Hg very easily coming from Git.
I may be wrong, but my perception is that Git has a bigger user community, probably due to it's use by the Linux kernel.
Thanks to the commenters: Git has Github - one of the best code hosting sites ever. (Trust me!)
A lot of high-profile projects use Git (the kernel, Rails, JQuery) - the Github repositories page is interesting - I am amazed at how many projects I recognise and use on a daily basis use Git!
Mercurial has a really, really good tutorial written by Joel Spolsky at hginit.com. It is the best tutorial on source control I've ever read! :)
I'd like to say something on the subject of benchmarks. There is a saying I like: "Never trust a benchmark you haven't faked yourself" :-)
Yes, the Git wiki lists benchmarks that tell you that Git is faster. You should take all benchmarks with a grain of salt, and two grains if they come from one of the contenders. For example, these Git benchmarks are taken on a clean Git repository, but they don't include the time needed to get it clean.
You see, Git has two repository formats: One is very fast for making commits, but is extremely space inefficient and as the repository grows in size other operations become slower. That's why they added a second repository format that cleans up unused files and stores the data more efficiently, thus reducing the footprint and improving performance. This is what the "git-gc" command does ("gc == garbage collection").
So guess what happens? When a Git benchmark reports a fast commit time, that is with one format, and when they report a small footprint or some fast operation, that is with the second format. And neither benchmark shows the cost of the garbage collection cycle. The result is that Git is made to look faster.
Note, I am not saying that Git is slow. But I do think that the benchmarks on the Git website overestimate its speed, and in particular, I am not confident that Git is actually faster than Mercurial.
Mercurial uses an efficient format that gives you a commit time "almost" as fast as the Git "fat" format, and a disk size "almost" as small as the Git "slim" format, without the cost of the garbage collection cycle in between.
Of course, another way in which benchmarks are never to be trusted is that there are many aspects to performance and people tend to report the ones that fit with their preconceived ideas. For example, I could point out than when Google Code came out they only supported Mercurial and not Git because Git's performance was too poor compared to Mercurial. But then, I would be omitting the fact that this was specifically an issue with performance over http.
I consider Hg relatively intuitive, easy to use and, when that fails, well documented.
Mercurial had an edge on Windows, but I believe Git improved there as well so it's probably not a good differentiator.
As far as the user interfaces go, you might consider TortoiseHg (the Windows shell integration you mentioned) to be of use if you don't like the command line. Working on Windows, I don't blame you. :)
Mercurial creates repositories the same way Git does: one, hidden subdirectory under the root direcory. You can move it around however you like (put it on a stick, take it elsewhere etc.) Why was that a problem with svn?
I'm happy to say that, considering Hg a tool to get a job done, I haven't felt the need to find a "good book". There might be some, but the available on-line docs were more than adequate for what I wanted to do.
While Git boasts its speed, it is unclear if it is faster than Mercurial, but the point is moot: they are really very fast anyway.
To paraphrase my own blog post on the subject, what I think matters a lot is that Git can’t seem to shake its reputation for being difficult to work with. A quote I ran into a few times illustrates this better than anything that comes to my mind: “Git’s changed, man! It’s not like it used to be, it’s totally intuitive now! You just gotta learn how it stores the data!”
To conclude, I'm a Mercurial user (haven't used Git, but have read about it a bit) and it's rare that I enjoy using a software product because 95+% of the time, they're raw, have rough edges, bugs etc. Mercurial is truly a solution I enjoy using and would heartily recommend!
My transition from Git to Mercurial has been a lot easier after reading A Guide to Branching in Mercurial, which also refers to the Git way of branching.
I'll recommend hgbook (Mercurial: The Definitive Guide) and hginit (Hg Init: a Mercurial tutorial. A friendly introduction to the Mercurial DVCS by Joel Spolsky.)
If you are happy with git, I doubt there is a real compelling reason to switch although I like Hg a lot. Git has TortoiseGit/GitCheetah, although I think TortoiseHg is a little better and stable IMHO.
You might want to watch this free video on using Hg and TortoiseHg (as well as the Visual Studio Hg plug-in) on tekpub/codeplex. The video will give you a feel for Hg.
I can't really talk about Mercurial, bit I can confirm git is written in C. Take a look at the gitweb for the source.
As for needing the commandline for everything to do with git, you don't necessarily need to. There's a tool called TortoiseGit which integrates with the explorer shell and will manage your git repositories for you - if you use Eclipse there's also EGit. On Linux, there's QGit although the CLI is much more powerful.
I'm a Linux/C developer and so naturally prefer Git; I too have heard good things about Mercurial though, I've just never bothered to learn it.
I have been using git and mercurial alternately for about 3 years now. I would strongly recommend mercurial if you need a stable source control system. We had serious stability issues when git used with Atlassian Stash. So we moved to mercurial and used SCM as authorization layer.
发布评论
评论（10）
Git 优点：
Git 缺点：
HG 优点：
HG 缺点：
还有其他显着差异，但这些是我的最重要的差异头脑。老实说，如果我主要在 Windows 上工作，我可能会选择 Mercurial。
Git Pros:
Git Cons:
HG Pros:
HG Cons:
There are other significant differences, but these are the most significant in my mind. Honestly, if I were mostly working on Windows, I would go probably go with Mercurial.
工程师也在这里。我使用过 Mercurial、Subversion、BitKeeper 和 CVS。还没接触到 Git。
不确定这里的意思，Git 和 Mercurial 本质上都是命令行工具。
它是一个分布式版本控制系统（DVCS），就像 Git 一样。
是的。 Mercurial 的存储库位于工作目录中的
.hg目录中。此外，Mercurial 在其存储库中有一个命名系统，如果您将其与 FAT、NTFS 或 HFS+ 等不区分大小写的文件系统一起使用，可以防止文件名冲突。我推荐该网站：https://www.mercurial-scm.org/guide
有一个名为 TortoiseHG 的工具。我无法证明它有多好，因为我通常只通过 Cygwin 使用命令行版本。
Mercurial 速度相当快。我不知道它与 Git 相比如何，但它比 Subversion 快得多。
听起来像我的东西。当然，不包括原始数据。
还有题外话...
我最近从 Matlab 转向 Python...
只是一个想法。
多年后编辑：有一个名为 SourceTree 我对此非常满意。它支持 Git 和 Mercurial，并且可以在 App Store 上免费下载。
Engineer here, too. I've used Mercurial, Subversion, BitKeeper, and CVS. Haven't made it to Git yet.
Not sure what was meant here, Git and Mercurial are both command-line tools at heart.
It's a distributed version control system (DVCS), just like Git.
Yes. Mercurial's repository lives in a
.hgdirectory in the working directory. Also, Mercurial has a naming system in its repository to prevent filename collisions if you use it with a case-insensitive filesystem like FAT, NTFS, or HFS+.I'd recommend the web site: https://www.mercurial-scm.org/guide
There's a tool called TortoiseHG. I can't attest to how good it is, since I usually just use the command-line version via Cygwin.
Mercurial is pretty darn fast. I don't know about how it stacks up with Git, but it's a lot faster than Subversion.
Sounds like my stuff. Not counting raw data, of course.
And off topic...
I've been moving from Matlab to Python recently...
Just a thought.
YEARS LATER EDIT: There is a Mac DVCS tool called SourceTree which I've been very happy with. It supports both Git and Mercurial, and is available for free on the App Store.
就您的观点而言：
In terms of your points:
我想谈谈基准测试的问题。我喜欢一句话：“永远不要相信你没有伪造过自己的基准”:-)
是的，Git wiki 列出了告诉你 Git 更快的基准。您应该对所有基准持保留态度，如果它们来自某个竞争者，则应持两粒态度。例如，这些 Git 基准测试是在干净的 Git 存储库上进行的，但它们不包括清理干净所需的时间。
您会看到，Git 有两种存储库格式：一种提交速度非常快，但空间效率极低，并且随着存储库大小的增长，其他操作会变得更慢。这就是为什么他们添加了第二种存储库格式，可以清理未使用的文件并更有效地存储数据，从而减少占用空间并提高性能。这就是“git-gc”命令的作用（“gc == 垃圾收集”）。
那么猜猜会发生什么？当 Git 基准测试报告快速提交时间时，即使用一种格式，而当它们报告占用空间小或某些快速操作时，即使用第二种格式。这两个基准都没有显示垃圾收集周期的成本。结果是 Git 看起来更快了。
注意，我并不是说 Git 很慢。但我确实认为 Git 网站上的基准高估了它的速度，特别是，我不相信 Git 实际上比 Mercurial 更快。
Mercurial 使用高效的格式，使您的提交时间“几乎”与 Git“胖”格式一样快，磁盘大小“几乎”与 Git“瘦”格式一样小，而无需花费垃圾收集周期的成本。之间。
当然，基准永远不值得信任的另一种方式是，性能有很多方面，人们倾向于报告符合他们先入为主的想法的方面。例如，我可以指出，当 Google Code 推出时，他们只支持 Mercurial，而不支持 Git，因为与 Mercurial 相比，Git 的性能太差了。但是，我会忽略这样一个事实：这是一个与 http 性能有关的具体问题。
I'd like to say something on the subject of benchmarks. There is a saying I like: "Never trust a benchmark you haven't faked yourself" :-)
Yes, the Git wiki lists benchmarks that tell you that Git is faster. You should take all benchmarks with a grain of salt, and two grains if they come from one of the contenders. For example, these Git benchmarks are taken on a clean Git repository, but they don't include the time needed to get it clean.
You see, Git has two repository formats: One is very fast for making commits, but is extremely space inefficient and as the repository grows in size other operations become slower. That's why they added a second repository format that cleans up unused files and stores the data more efficiently, thus reducing the footprint and improving performance. This is what the "git-gc" command does ("gc == garbage collection").
So guess what happens? When a Git benchmark reports a fast commit time, that is with one format, and when they report a small footprint or some fast operation, that is with the second format. And neither benchmark shows the cost of the garbage collection cycle. The result is that Git is made to look faster.
Note, I am not saying that Git is slow. But I do think that the benchmarks on the Git website overestimate its speed, and in particular, I am not confident that Git is actually faster than Mercurial.
Mercurial uses an efficient format that gives you a commit time "almost" as fast as the Git "fat" format, and a disk size "almost" as small as the Git "slim" format, without the cost of the garbage collection cycle in between.
Of course, another way in which benchmarks are never to be trusted is that there are many aspects to performance and people tend to report the ones that fit with their preconceived ideas. For example, I could point out than when Google Code came out they only supported Mercurial and not Git because Git's performance was too poor compared to Mercurial. But then, I would be omitting the fact that this was specifically an issue with performance over http.
我会一点一点地讲……
我认为 Hg 相对直观、易于使用，并且在失败时有详细的记录。
Mercurial 在 Windows 上有优势，但我相信 Git 在这方面也有所改进，所以它可能不是一个很好的差异化因素。
就用户界面而言，如果您不喜欢命令行，您可能会考虑使用 TortoiseHg（您提到的 Windows shell 集成）。在 Windows 上工作，我不怪你。 :)
Mercurial 创建存储库的方式与 Git 相同：一是根目录下的隐藏子目录。你可以随心所欲地移动它（把它放在一根棍子上，把它带到其他地方等等）。为什么这是 svn 的问题？
我很高兴地说，考虑到 Hg 是完成工作的工具，我并不觉得有必要找到一本“好书”。可能有一些，但可用的在线文档足以满足我的需求做。
尽管 Git 夸耀其速度，但不清楚是否它比 Mercurial 更快，但重点是：无论如何它们确实非常快。
套用我自己的博客关于这个主题，我认为最重要的是 Git 似乎无法摆脱其难以使用的声誉。我多次遇到的一句话比我想到的任何事情都更能说明这一点：“Git 改变了，伙计！它不像以前那样，现在完全直观！你只需要了解它如何存储数据！”
总而言之，我是 Mercurial 用户（没有使用过 Git，但读过一些相关内容），而且我很少喜欢使用软件产品，因为 95% 以上的时间，它们都是原始的、有粗糙的边缘Mercurial 确实是我喜欢使用并衷心推荐的解决方案！
I'll take it point by point...
I consider Hg relatively intuitive, easy to use and, when that fails, well documented.
Mercurial had an edge on Windows, but I believe Git improved there as well so it's probably not a good differentiator.
As far as the user interfaces go, you might consider TortoiseHg (the Windows shell integration you mentioned) to be of use if you don't like the command line. Working on Windows, I don't blame you. :)
Mercurial creates repositories the same way Git does: one, hidden subdirectory under the root direcory. You can move it around however you like (put it on a stick, take it elsewhere etc.) Why was that a problem with svn?
I'm happy to say that, considering Hg a tool to get a job done, I haven't felt the need to find a "good book". There might be some, but the available on-line docs were more than adequate for what I wanted to do.
While Git boasts its speed, it is unclear if it is faster than Mercurial, but the point is moot: they are really very fast anyway.
To paraphrase my own blog post on the subject, what I think matters a lot is that Git can’t seem to shake its reputation for being difficult to work with. A quote I ran into a few times illustrates this better than anything that comes to my mind: “Git’s changed, man! It’s not like it used to be, it’s totally intuitive now! You just gotta learn how it stores the data!”
To conclude, I'm a Mercurial user (haven't used Git, but have read about it a bit) and it's rare that I enjoy using a software product because 95+% of the time, they're raw, have rough edges, bugs etc. Mercurial is truly a solution I enjoy using and would heartily recommend!
阅读 A Guide to Branching in Mercurial，也指的是 Git 的分支方式。
如果您有 IIS 7，则可以轻松设置 Mercurial 服务器：设置 Mercurial服务器在 Windows Server 2008 R2 上的 IIS7 下，您可以轻松找到使用 IIS 6 或 Apache2 的教程。当然，对于快速同步来说，
hgserve是非常有价值的：使用“hgserve”推送更改Visual Studio 集成：
免费托管：
有关指南和教程，您可以从 Mercurial wiki 开始。
My transition from Git to Mercurial has been a lot easier after reading A Guide to Branching in Mercurial, which also refers to the Git way of branching.
If you have IIS 7, you can easily set up a Mercurial server: Setting up a Mercurial server under IIS7 on Windows Server 2008 R2, and you can easily find tutorials using IIS 6 or Apache2. Of course, for a quick sync
hg serveis invaluable: using "hg serve" to push changesVisual Studio integration:
Free hosting:
For guides and tutorials you can start at the Mercurial wiki.
我会推荐 hgbook （Mercurial：权威指南）和 hginit （Hg Init：Mercurial 教程。Joel Spolsky 对 Mercurial DVCS 的友好介绍。）
另请参阅我在 Git 和 Mercurial - 比较和对比 所以问题。
I'll recommend hgbook (Mercurial: The Definitive Guide) and hginit (Hg Init: a Mercurial tutorial. A friendly introduction to the Mercurial DVCS by Joel Spolsky.)
See also my answer in Git and Mercurial - Compare and Contrast SO question.
如果你对 git 感到满意，我怀疑是否有真正令人信服的理由去切换，尽管我非常喜欢 Hg。 Git 有 TortoiseGit/GitCheetah，不过恕我直言，我认为 TortoiseHg 更好一点，更稳定一些。
您可能想在 tekpub/ 上观看有关使用 Hg 和 TortoiseHg（以及 Visual Studio Hg 插件）的免费视频代码复合体。该视频将让您感受汞。
If you are happy with git, I doubt there is a real compelling reason to switch although I like Hg a lot. Git has TortoiseGit/GitCheetah, although I think TortoiseHg is a little better and stable IMHO.
You might want to watch this free video on using Hg and TortoiseHg (as well as the Visual Studio Hg plug-in) on tekpub/codeplex. The video will give you a feel for Hg.
我不能真正谈论 Mercurial，但我可以确认 git 是用 C 编写的。看看 gitweb 获取源代码。
至于与 git 相关的所有事情都需要命令行，你不一定需要。有一个名为 TortoiseGit 的工具，它与资源管理器 shell 集成，将为您管理 git 存储库 - 如果您使用 Eclipse还有EGit。在 Linux 上，有 QGit，尽管 CLI 更强大。
我是一名 Linux/C 开发人员，所以自然更喜欢 Git；我也听说过有关 Mercurial 的好消息，但我从来没有费心去学习它。
I can't really talk about Mercurial, bit I can confirm git is written in C. Take a look at the gitweb for the source.
As for needing the commandline for everything to do with git, you don't necessarily need to. There's a tool called TortoiseGit which integrates with the explorer shell and will manage your git repositories for you - if you use Eclipse there's also EGit. On Linux, there's QGit although the CLI is much more powerful.
I'm a Linux/C developer and so naturally prefer Git; I too have heard good things about Mercurial though, I've just never bothered to learn it.
我已经交替使用
git和mercurial大约 3 年了。如果您需要稳定的源代码控制系统，我强烈推荐 Mercurial。当git与Atlassian Stash一起使用时，我们遇到了严重的稳定性问题。因此，我们转向mercurial并使用SCM作为授权层。I have been using
gitandmercurialalternately for about 3 years now. I would strongly recommend mercurial if you need a stable source control system. We had serious stability issues whengitused withAtlassian Stash. So we moved tomercurialand usedSCMas authorization layer.