为什么认为Mercurial比Git容易？

#1 楼

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

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

命令行：

<oldname>=<newname>

现在，看起来更容易使用吗？


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

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

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

面向命令行的方法并且是linux程序，这意味着几乎所有方法指南，帮助文档和论坛/ 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上是地狱），我没有愚蠢的复杂命令，没有追随者，没有疯狂。 Mercurial可以正常工作。

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的怪兽之间。

水银每次都会起作用。 Git挡住了我，只会越发激怒我。

#2 楼

Git vs Mercurial


人们普遍认为Mercurial比Git更简单易学。
反过来，人们通常会认为
Git更加灵活并且功能强大。这部分是由于
，因为Git倾向于提供更多的
低级命令，也部分是由于
，因为默认的Mercurial往往会隐藏高级功能，而保留它以便
用户编辑Mercurial config
文件以激活他们喜欢的高级功能。这通常会导致人们
认为高级功能
在Mercurial中不可用。


Git概念
一直更加关注
界面方面，这使得它本来就更容易学习。与Git相比，需要以一种有用的方式对
进行更深入的了解。从长远来看，这样的封装使Mercurial具有虚假的外观
，而其功能和功能却不如实际。

#3 楼

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

一般来说，我发现Mercurial更易于使用。我发现一些使Mercurial更容易的方法：



索引不足。索引是启用Git的许多功能的强大工具，但它还是一个额外的层，可增加我经常做的许多事情。 Mercurial的工作流程更类似于svn。

版本号代替shas。我发现这是一件小事，在Mercurial中，每天使用命令变得非常容易。在编写命令时，在进行变基，合并等操作时，将一些修订版本号推入您的头脑要比使用什至更短的shas更容易。

分支。 Git通过命名提交来分支的方法功能强大，并且与其他版本控制系统完全不同。它使某些事情变得容易得多。我发现Mercurial的方法与svn的思想更好地匹配，并且更容易从视觉上理解分支的历史。这可能只是一个首选项。

#4 楼

这是非常主观的，并且取决于一个人，但是，是的，我想告诉那些完全不接触VCS的人或某个来自“老派” VCS的人，Mercurial看起来会更容易。 >例如，添加文件，以Hg表示不存在索引，返回某些旧版本并从那里进行分支（仅更新和提交）的简便性，这是一些“最明显”的示例。现在，一个系统的大多数功能可以在另一个系统中进行仿真，反之亦然，但这需要在Git中有一定的知识，而在Mercurial中，默认值（如果允许的话）是“用户友好的”。这些小东西-到处切换，一个命令中的非显而易见行为等等...这些东西加在一起，最后，一个系统似乎比另一个系统更易于使用。 br只需使答案完整即可；我使用git，但是当为“新手”推荐VCS时，我几乎总是推荐Mercurial。我记得，当它第一次出现在我手中时，感觉非常直观。根据我的经验，Mercurial的wtf / min低于Git。

#5 楼

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

#6 楼

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

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

关于GIT /商品复杂性的反例：Mac上的XCode内置了对GIT的良好支持。与Meritial一起使用XCode不如GIT容易。

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

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

我不那么喜欢党派，以至于100％赞成水银，而100％反对git。我现在对Mercurial，Windows和Linux都比较满意，当我开始做更多的Mac工作时，我希望我会尽量坚持使用XCode + GIT。2013年更新：我现在已经使用Mercurial AND GIT了足够长的时间，以查找一些我希望它具有Git的功能，例如关于合并策略的问题。真的，Git很棒，即使很难学习，有时也非常复杂。

#7 楼

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


Git文化更以命令行为中心。虽然这两种工具的确倾向于过多地关注命令行（正如我多次提到的那样，命令行指令可能功能强大且更流畅，但它们并不是一种好的营销策略），但Git的情况尤其如此。 Mercurial在TortoiseHg中具有事实上的标准GUI工具，甚至是Mercurial主页上Windows用户的默认下载选项，而Git具有一些竞争的GUI前端（TortoiseGit，Git Extensions，gitk等），它们的广告宣传不佳在Git网站上，反正这一切都是令人讨厌的。 （红色标签上的黑色文字？来吧，TortoiseGit，您可以做得更好！）Git社区中还普遍存在一种态度，即使用GUI工具的人不是合适的软件开发人员。有几种开箱即用的默认设置对高级用户来说是很有意义的，但如果不吓到新用户，则可能会令人惊讶。例如，自动化诸如合并之类的任务要积极得多（例如，git pull在可能的情况下自动合并并提交）。有一种完全自动合并的情况，但是大多数经验不足的用户对合并感到恐惧，因此需要在释放其源代码功能之前，有机会获得对其工具的信心。

文档和固有的复杂性：

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

#8 楼

我能想到的一件事是

git add .
git commit -am "message"

vs.

hg ci -Am "message"

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

#9 楼

因为它是。

Git暴露的胆量远远超过了汞。您可以在捡起它后的几分钟内愉快地使用Mercury，但是经过几个月的搏斗，我发现git仍然很难解决（除了尝试学习git以外，我在过去几个月中几乎没有做过）。我既从命令行使用命令行，又在Linux上使用，所以这不仅是对命令行界面的厌恶。 git。临时区域和git中add命令的行为也增加了不必要的复杂性。重置，检出和还原这三者及其多重排列增加了巨大的复杂性，当您看到还原和更新汞的直接本质时，这是不必要的。

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