为什么认为Mercurial比Git容易？

在进行比较时，在我看来，它们的功能集之间可能存在1：1的映射。然而，经常被引用的说法是“ Mercurial更容易”。该声明的依据是什么？（如果有）

恰当的例子：假设您要更改所有先前提交的用户名。由于各种原因，我需要多次执行此操作。

Git版本

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD

水星版本：

authors.convert.list文件：

<oldname>=<newname>

命令行：

hg convert --authors authors.convert.list SOURCE DEST

现在，哪个看起来更易于使用？

注意：我花了2年的时间专门与Git一起工作，所以这不是“我讨厌它，我2秒钟内没有得到它”。

对我来说，就是可用性。Git是非常面向Linux的，具有Linux的处理方式。这意味着命令行，手册页，并自己解决。它的GUI非常差（请注意：大约从一年前开始，我就基于msysGit了），这似乎妨碍了我的工作。我几乎用不了

命令行更糟。作为面向Linux的程序，在Windows上很难使用。他们没有使用本地端口，而是仅将git与MinGW（Think cygwin）包装在一起，这使得使用它变得更加困难。MinGW不是Windows命令提示符，只是行为有所不同。疯狂的是，这是与Git一起工作的唯一方法。即使在Linux中，似乎唯一的方法就是使用直接命令行。诸如RabbitVCS之类的项目有所帮助，但功能却不是很强大。

面向命令行的方法并且是linux程序，这意味着几乎所有的howto指南，帮助文档和论坛/ QA问题都依赖于运行上述可怕的命令。基本的SCM命令（commit，pull，push）并不那么复杂，但是更多，并且复杂性呈指数增长。

我也讨厌很多OSS git用户似乎流连忘返的地方：Github。当您第一次进入github页面时，它会以您可能会做的一切让您大跌眼镜。对我来说，一个项目git页面看起来混乱，可怕并且过于强大。甚至对项目含义的解释也被推到最底层。Github确实伤害了尚未设置完整网站的人们。它的问题跟踪器也很可怕且令人困惑。功能超载。

Git用户似乎也很喜欢。Git用户似乎总是开始进行DVCS更好的“圣战”，然后迫使Mercurial用户捍卫自己。像http://whygitisbetterthanx.com/之类的网站显示出傲慢的态度和几乎“使用我的软件或死亡”的心态。很多时候，我进入各种帮助的地方只是因为不了解X，事先使用X，使用Windows等而被解雇。这太疯狂了。

另一方面，水银似乎朝着更友善的方向发展。对于新用户而言，他们自己的主页似乎比Git的友好得多。在一个简单的Google搜索中，第五个结果是TortoiseHg，这是Mercurial的非常好的GUI。他们的整个方法似乎首先是简单，然后是电源。

使用Mercurial，我没有SSH废话（SSH在Windows上是地狱），我没有愚蠢的复杂命令，没有追随者，没有疯狂。水银只是工作。

TortoiseHg提供了一个实际可用的界面（尽管最近似乎正在增长），该界面提供了实际有用的功能。选项仅限于您需要的选项，可消除混乱情况和很少使用的选项。它还提供了许多不错的默认设置

Mercurial对新手非常友好，很容易拿起。即使是一些更复杂的主题，例如不同的分支模型和历史记录编辑，也很容易遵循。我迅速而轻松地接了水星。

Mercurial只需很少的设置即可首次使用。在任何操作系统上，我都可以安装TortoiseHg并获得我想要的所有功能（主要是上下文菜单命令），而不必寻找其他Guis。还缺少设置SSH（一半的指南说使用Putty，Plink和Pagent，而另一半则说使用ssh-keygen）。对于新用户，TortoiseHg需要花费几分钟的时间来设置，而Git则需要花费30分钟到一个小时的时间来进行大量的谷歌搜索。

最后，您有了在线回购。Githubs相当于BitBucket，它具有我上面概述的一些问题。但是，还有Google Code。当我进入Google Code项目时，不会出现功能重载，而是得到了一个不错的简洁界面。Google Code更像是在线回购/网站组合，确实可以帮助没有现有站点设置的OSS项目。在相当长的一段时间内使用Google Code作为我的项目网站时，我会感到非常自在，只在绝对必要时才建立网站。它的问题跟踪器也功能强大，非常适合Github几乎没有用的问题跟踪器和Bugzilla的怪兽之间。

Mercurial每次都可以正常工作。Git妨碍了我，只会在我使用它时更激怒我。

Git与Mercurial

人们普遍认为Mercurial比Git更简单易学。反过来，人们通常认为Git更加灵活和强大。这部分是由于Git倾向于提供更多的低级命令，另一部分是由于默认的Mercurial 倾向于隐藏高级功能，而让用户编辑Mercurial配置文件以激活他们喜欢的高级功能。这通常会导致人们认为Mercurial无法使用高级功能。

Git概念

Mercurial一直将重点更多地放在界面方面，这使得它本来更容易学习。与Git相比，以一种有用的方式对Mercurial进行操作需要较浅的理解。从长远来看，这种封装使Mercurial看起来不像实际那样功能强大，功能不足。

上下文：我每天都使用Mercurial（用于工作）和Git（用于辅助项目和开源）。我主要同时使用基于文本的工具（而不是IDE），并且在Mac上。

总的来说，我发现Mercurial更易于使用。我发现一些使Mercurial更容易的事情：

1. 缺少索引。 索引是启用Git的许多功能的强大工具，但它还是一个额外的层，可增加我经常做的许多事情。Mercurial的工作流程更类似于svn。
2. 修订号，而不是shas。 我发现这是一件小事，使Mercurial中的日常命令操作变得更加轻松。在编写命令时，在进行变基，合并等操作时，将一些修订号推入您的头脑要比用短一些的shas更容易。
3. 分支机构。 Git通过命名提交来分支的方法功能强大，并且与其他版本控制系统完全不同。它使某些事情变得容易得多。我发现Mercurial的方法与svn的思想更好地匹配，并且更容易从视觉上理解分支的历史。这可能只是一个偏好。

这是非常主观的，并且取决于一个人，但是，是的，我想告诉那些完全不接触VCS的人或某个来自“老派” VCS的人，Mercurial看起来会更容易。

例如，添加文件，以Hg形式不存在索引，返回某些旧版本以及从那里进行分支（仅更新和提交）的简便性（作为最“明显”的示例）。现在，一个系统的大多数功能可以在另一个系统中进行仿真，反之亦然，但这需要在Git中有一定的知识，而在Mercurial中，默认值（如果允许的话）是“用户友好的”。这些小事情-到处切换，一个命令中的非显而易见行为等等……这些事情加在一起，最后，一个系统似乎比另一个系统更易于使用。

只是为了使答案完整；我使用git，但是当为“新手”推荐VCS时，我几乎总是推荐Mercurial。我记得，当它第一次出现在我手中时，感觉非常直观。根据我的经验，Mercurial的wtf / min低于Git。

我认为这很简单：Mercurial具有更熟悉的语法（特别是对于SVN用户），并且文档齐全。一旦习惯了Git语法，您就会发现它与其他任何东西一样容易使用。

对此，认知可能会随着时间而改变。Mercurial的设计非常好，Git也是如此。Mercurial似乎更容易学习（至少对我来说是这样），并且在Git中遇到了很多困难，而我在Mercurial中没有类似的困难。我尝试学习Python和Ruby，并通过Python更快，更快速地学习。这并不意味着Python永远在任何地方都比Ruby更好，甚至不代表我更好。这就是我所学并坚持的。程序员经常出于个人喜好进行圣战。其他人也这样做。

我是一名购物狂，试图对Git保持开放态度，我自由地承认，它没有像Mercurial那样“成为我的新宠”。我认为Git确实非常好。

GIT /商品复杂性的反例：Mac上的XCode内置了对GIT的良好支持。与Mercurial相比，将XCode与Mercurial结合使用不那么容易。

到目前为止，我在GIT方面的经验使我感到困惑和迷失，在使用它时需要更多地查阅文档。我相信已经写了很多文档，但是没有什么能使我“理解”。其次，我可以轻松地在Python中修改和扩展Mercurial，并且由于我精通Python，并且因为任何人都可以真正快速地学习python，所以这对我来说似乎是一个优势。我也了解C，并且用C编写Python扩展，所以我想有一天，如果需要的话，我可以轻松地用C编写Git扩展。

易用性不容易量化。它在那里，我不认为它完全是主观的，但是我们没有良好的客观测量技术。易于使用的单位是什么？Milli-iPods？

我不那么有党派倾向，要成为100％赞成水手和100％反对git。我现在对Mercurial，Windows和Linux都比较满意，当我开始做更多的Mac工作时，我希望我会坚持使用XCode + GIT。

更新2013：我现在已经使用水银和Git足够长的时间来发现，我希望它有这样的Git有，如一些功能此有关合并的战略问题。如果很难学习，有时甚至是疯狂地复杂，它真的很棒。

IMO可能会使Git失去新用户：

1. Git文化更以命令行为中心。虽然这两种工具的确倾向于将重点放在命令行上（正如我多次说过的那样，命令行指令可能功能强大且更流畅，但它们并不是一种好的营销策略），但Git的情况尤其如此。Mercurial在TortoiseHg中具有事实上的标准GUI工具，甚至是Mercurial主页上Windows用户的默认下载选项，而Git具有几个竞争的GUI前端（TortoiseGit，Git Extensions，gitk等），它们的广告宣传不佳在Git网站上，反正这一切都是令人讨厌的。（红色标签上的黑色文字？来吧，TortoiseGit，您可以做得更好！）Git社区中还普遍存在一种态度，即使用GUI工具的人不是合适的软件开发人员。

2. Git有一些现成的默认值，这些默认值对高级用户来说非常有意义，但是如果不吓到新用户，可能会令人惊讶。例如，在自动化诸如合并之类的任务时，它更具攻击性（例如，git pull在可能的情况下自动合并并提交）。全自动合并是有必要的，但是大多数没有经验的用户对合并感到恐惧，需要在他们的源代码完全发挥作用之前有机会获得对其工具的信心。

3. 文档和固有的复杂性：

   $ hg help log | wc -l
   64
   $ git help log | wc -l
   912
   

我能想到的一件事是

git add .
git commit -am "message"

与

hg ci -Am "message"

git commit -a不会添加新创建的文件，而是添加hg ci -A，这意味着可以使用Mercurial中的一个命令来完成需要使用git的两个命令的操作。再说一次，“较少键入”并不一定意味着“更加用户友好”。

因为它是。

Git暴露的胆量远远超过了汞。您可以在捡起它后的几分钟内愉快地使用Mercury，但是经过几个月的搏斗，我发现git仍然很难解决（除了尝试学习git以外，我在过去几个月中几乎没有做过）。我既从命令行使用命令行，又在Linux上使用，所以这不仅是对命令行界面的厌恶。

一个简单的例子是与git相比，Mercurial所需的标志和命令行参数相对较少。临时区域和git中add命令的行为也增加了不必要的复杂性。重置，检出和还原这三者及其多重排列增加了极大的复杂性，当您看到还原和更新汞的直接本质时，这是不必要的。

我也同意以上关于Hginit的评论，它无疑使人们容易理解。写得很好，很容易理解。没有为git编写的文档接近。首先，我发现Scott Chacone（他一手编写了大多数有关git的文档/书籍）所写的大部分内容特别令人困惑。