MercurialがGitよりも簡単だと考えられているのはなぜですか？
比較を見ると、機能セット間に1対1のマッピングがあるように思えます。しかし、しばしば引用される声明は「水銀はより簡単である」というものです。この声明の根拠は何ですか？ （存在する場合）
適例：以前のすべてのコミットでユーザー名を変更するとします。さまざまな理由でこれを数回行う必要がありました。
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
Mercurialバージョン：
authors.convert.listファイル：
<oldname>=<newname>
コマンドライン：
hg convert --authors authors.convert.list SOURCE DEST
さて、どちらが使いやすく見えますか？
注：私は2年間Gitだけで作業していたので、これは「嫌いです。2秒以内に取得できませんでした」という発言ではありません。
私にとって、それはユーザビリティです。 Gitは非常にLinux指向であり、Linuxで物事を行う方法を備えています。つまり、コマンドライン、マニュアルページ、そしてそれを自分で理解することです。それは非常に貧弱なGUI（注：私はこれを約1年前からmsysGitに基づいています）を持っていて、それは私の邪魔をするように思われました。かろうじて使える
コマンドラインはもっと悪かった。 Linux指向のプログラムであるため、Windowsでの使用は非常に困難でした。ネイティブポートの代わりに、彼らは単にgitをMinGW（cygwinだと思います）でラップしました。 MinGWはWindowsのコマンドプロンプトではなく、動作が異なります。これがGitで作業するための唯一の方法であることはおかしいです。 Linuxでも、まっすぐなコマンドラインで作業するのが唯一の方法のように思われました。 RabbitVCSのようなプロジェクトは一部を助けましたが、それほど強力ではありませんでした。
コマンドライン指向のアプローチとLinuxプログラムであることは、ハウツーガイド、ヘルプドキュメント、フォーラム/ QAの質問のほとんどすべてが、上記のような巨大なコマンドの実行に依存していたことを意味します。基本的なSCMコマンド（commit、pull、Push）はそれほど複雑ではありませんが、複雑さは指数関数的に増大します。
また、多くのOSS gitユーザーがたむろしているように見える1つの場所、Githubも嫌いです。最初にgithubページにアクセスすると、できる限りのことすべてが表示されます。私には aプロジェクトのgitページ は無秩序で恐ろしく、非常に強力に見えます。プロジェクトが何であるかの説明でさえ、下に押し下げられます。 Githubは、完全なウェブサイトをまだセットアップしていない人々を本当に傷つけます。その課題追跡もひどくて混乱しています。機能の過負荷。
Gitユーザーも非常にカルト的であるように思われました。 Gitユーザーは常にDVCSの方が優れている「ホーリーウォーズ」を開始するユーザーであり、それによってMercurialユーザーは自分自身を守る必要があります。 http://whygitisbetterthanx.com/ のようなサイトは、傲慢さとほとんど「私のソフトウェアを使用するか死ぬか」という考え方を示しています。 Xを知らない、Xを事前に使用する、Windowsを使用するなどの理由で、さまざまなヘルプの場所に何度も行き来しました。
一方、Mercurialはより親切なアプローチに向かっているようです。独自の ホームページ は Git's よりも、新しいユーザーにとってはるかに親しみやすいようです。単純なGoogle検索で5番目の結果は、TertoiseHgであり、Mercurialにとって非常に優れたGUIです。彼らの全体的なアプローチは、最初は単純で、後で力を発揮するようです。
Mercurialでは、SSHのナンセンスはありません（SSHはWindowsでは地獄です）、愚かなほど複雑なコマンドはありません。カルトユーザーをフォローしていません。 Mercurialは機能します。
TortoiseHgは、実際に有用な機能を提供する（最近は成長しているようですが）実際に使用可能なインターフェースを提供します。オプションは必要なものに限定され、ごちゃごちゃとほとんど使用されないオプションが削除されます。それはまた多くのまともなデフォルトを提供します
Mercurialは、新規参入者に非常に親切で、簡単に入手できました。異なる分岐モデルや履歴の編集など、より複雑なトピックのいくつかでさえ、非常に簡単に理解できました。 Mercurialをすばやく簡単に拾いました。
Mercurialも、ほとんど設定をせずに初めて機能します。どのOSでも、TortoiseHgをインストールして、さまざまなGuiを探す必要なく、必要なすべての機能（主にコンテキストメニューコマンド）を取得できます。また、SSHの設定も欠落しています（そこにあるガイドの半分はPuTTY、Plink、Pagentを使用するように言っているのに対し、残りの半分はssh-keygenを使用するように言っています）。新規ユーザーの場合、TortoiseHgのセットアップには数分かかりますが、Gitにはグーグルが多く、30分から1時間かかります。
最後に、オンラインリポジトリがあります。 Githubに相当するのはBitBucketで、これには上記で概説した問題のいくつかがあります。ただし、Google Codeもあります。 Google Codeプロジェクト にアクセスすると、機能の過負荷が発生せず、すっきりとしたインターフェースが表示されます。 Google Codeは、オンラインのリポジトリとWebサイトの組み合わせであり、既存のサイト設定を持たないOSSプロジェクトを本当に助けます。私はかなり長い間、Google Codeを私のプロジェクトのWebサイトとして使用することにとても満足しています。その課題追跡も強力で、Githubのほとんど役に立たない課題追跡と Bugzillaの怪物 の間にうまく収まります。
Mercurialは、初めて、常に、常に機能します。 Gitが邪魔になり、使うほどに怒るだけです。
Mercurialは一般に、Gitよりも学習が簡単で簡単であると考えられています。次に、Gitはより柔軟で強力であるという認識がしばしばあります。これは、一部はGitがより低レベルのコマンドを提供する傾向があるためですが、一部はデフォルトのMercurialが高度な機能を非表示にする傾向があるためです、 Mercurial構成ファイルを編集して、好みの拡張機能をアクティブにするのはユーザーに任せます。これにより、Mercurialでは高度な機能を利用できないという認識がしばしばあります。
Mercurialは常にインターフェースの側面に重点を置いてきたため、当初は習得が容易でした。 Gitと比較して、Mercurialを効果的に操作するには、より深い理解が必要です。長い目で見れば、そのようなencapsulationはMercurialに、実際よりも強力で機能的ではないという誤った外観を与えました。
コンテキスト：Mercurial（仕事用）とGit（サイドプロジェクトとオープンソース用）の両方を日常的に使用しています。私は主に両方の（IDEではなく）テキストベースのツールを使用しており、Macを使用しています。
一般的に、Mercurialの方が扱いやすいと思います。私が見つけたいくつかのことはMercurialをより簡単にします：
- インデックスの欠如。インデックスは、Gitの多くの機能を有効にする強力なツールですが、定期的に行う多くのことへのステップを追加する追加のレイヤーでもあります。 Mercurialのワークフローは、svnのようなものに似ています。
- shasの代わりにリビジョン番号。これは、Mercurialで毎日のコマンドを簡単に操作できるようにする小さなことです。コマンドを書いている間、リベース、マージなどの間にいくつかのリビジョン番号を頭にプッシュする方が、短縮されたshaで同じことをするよりもはるかに簡単です。
- ブランチ。コミットに名前を付けることによるブランチへのGitのアプローチは強力で、他のバージョン管理システムとは大きく異なります。それはある事柄をずっと簡単にします。 Mercurialのアプローチはsvnの考え方に少し一致し、ブランチの履歴を視覚的に理解しやすくなることがわかりました。これは単なる好みかもしれません。
これは非常に主観的であり、人から人へと依存しますが、そうです、VCSの完全に新しい人、または「古い」VCSの1人から来た人に行けば、Mercurialはより簡単に見えます。
たとえば、ファイルを追加する、Hgにインデックスが存在しない、最もわかりやすい例として、古いリビジョンに戻ってそこから分岐すること（更新とコミットのみ）の容易さなどがあります。現在、1つのシステムのほとんどの機能を別のシステムでエミュレートでき、その逆も可能ですが、Gitである程度の知識が必要ですが、Mercurialでは、デフォルトで（ユーザーがそれを呼び出すことができる場合）は「ユーザーフレンドリー」です。それらの小さなこと-あちこちのスイッチ、1つのコマンドでの非自明な動作など...これらのことは合算され、最終的に、1つのシステムは他のシステムよりも使いやすいように見えます。
答えを完全にするためだけに。私はgitを使用していますが、「初めて」の人にVCSを推奨するときは、ほとんど常にMercurialを推奨します。最初に手にしたとき、それは非常に直感的に感じました。 MercurialはGitよりもwtf /分が少ないというのが私の経験です。
Mercurialはより身近な構文（特にSVNユーザー向け）を備えており、かなりよく文書化されています。 Git構文に慣れると、他の構文と同じくらい簡単に使用できるようになります。
これに関して、認識は時間とともに変化する可能性があります。 Mercurialは非常によく設計されており、Gitもそうです。 Mercurialの方が学習しやすいようで（少なくとも私にとってはそうでした）、Gitで遭遇した困難がありましたが、Mercurialには同じようなことはありません。私はPythonとRubyを学ぼうとしましたが、Pythonを使うことでさらに速くなりました。 PythonがいつでもどこでもRubyよりも優れている、または私にとってより優れているという意味ではありません。それは、私が学んでこだわったことです。プログラマは、しばしば個人的な好みから聖戦を行います。他の人間もそうします。
私はMercurialのユーザーであり、Gitについてオープンな心を持ち続けることを心がけていますが、Gercurialと同じ程度に「新しいお気に入りのもの」にならないことを自由に認めています。 Gitは本当に素晴らしいと思います。
GIT/Mercurialの複雑さの反例：Macでは、ニースなGITサポートがXCodeに組み込まれています。 GITよりもMercurialでのXCodeの使用は簡単ではありません。
私のこれまでのGITの経験では、混乱して失ってしまい、GITを使用している間はもっとドキュメントを参照する必要があります。たくさんのドキュメントが書かれていると思いますが、それを「手に入れる」ことを可能にしたものは何もありません。次に、MercurialをPythonで簡単に変更および拡張できます。Pythonに習熟しているため、誰もがすぐにpythonをすぐに習得できるので、私には利点のようです。Cも知っています。 CでPython Extensionsを書くので、いつか必要な場合は、CでGit拡張機能を簡単に書くことができます。
使いやすさは、簡単に数値化できるものではありません。それはそこにあり、私はそれが完全に主観的であるとは思いませんが、私たちは良い客観的な測定技術を持っていません。使いやすさの単位とは？ミリiPod？
私は100％プロ水銀であり、100％反Gitであるほど党派ではありません。今はMercurial、Windows、Linuxの方が快適です。Macでの作業を始めるときは、XCode + GITを使い続けるつもりです。
2013年の更新：私はMercurial AND GITを十分に長く使用して、Gitが持っていれば this マージ戦略に関する質問。本当にGitは驚くべきものであり、学ぶのが難しい場合、そして時として厄介なほど複雑です。
IMOが新しいユーザーをGitから離脱させる可能性がいくつかあります。
Gitカルチャーは、コマンドライン中心です。どちらのツールもコマンドラインに重点を置く傾向があります（私が何度か言ったように、コマンドラインの指示は強力で流暢かもしれませんが、 これらは優れたマーケティング戦略ではありません ）これはGitの場合はもっと多くなります。 MercurialにはTortoiseHgの事実上の標準GUIツールがあり、これはMercurialホームページのWindowsユーザー向けのデフォルトのダウンロードオプションですが、Gitにはいくつかの競合するGUIフロントエンド（TortoiseGit、Git Extensions、gitkなど）があり、十分に宣伝されていません。 GitのWebサイトで、とにかくすべて完全に目障りです。 （赤いラベルに黒いテキストが表示されますか？C'mon、TortoiseGit、あなたはそれよりも上手にできます！）GUIツールを使用する人々は適切なソフトウェア開発者ではないというGitコミュニティには、はるかに広まった態度もあります。
Gitには、すぐに使えるデフォルトがいくつかあり、上級ユーザーには完全に理にかなっていますが、新しいユーザーに威圧的でない場合は意外なものになる可能性があります。たとえば、マージなどのタスクの自動化についてははるかに積極的です（たとえば、可能であればgit pullは自動的にマージしてコミットします）。 完全に自動化されたマージの場合があります ですが、経験の浅いユーザーのほとんどはマージを恐れており、ソースコードを最大限に活用する前にツールに自信をつける機会を与える必要があります。
ドキュメントと固有の複雑さ：
$ hg help log | wc -l 64 $ git help log | wc -l 912
その理由は。
GitはMercurialよりもはるかに多くの根性を公開しています。 Mercurialは、手に取ってから数分以内で問題なく使用できますが、2か月間取り組んできた後でも、Gitの取り組みはまだ非常に難しいと感じています（過去2か月間、Gitを習得する以外はほとんど何もしていません） ）。私はコマンドラインとほとんどLinuxで両方を使用しているので、これはコマンドラインインターフェースへの嫌悪ではありません。
簡単な例の1つは、Gitと比較してMercurialに必要なフラグとコマンドライン引数が比較的少ないことです。ステージング領域とgitのaddコマンドの動作も、必要以上に複雑になります。リセット、チェックアウト、および復帰のトリオとそれらの複数の順列により、非常に複雑になります。これは、Mercurialで復帰と更新の単純な性質を確認する場合にはまったく必要ありません。
Hginit についても上記のコメントに同意します。これにより、Mercurialが理解しやすくなりました。よく書かれていて、とても理解しやすいです。 git向けに書かれたドキュメントはどれも近くありません。私にとって、特に混乱しているのは、Scott Chacone（Gitに関するドキュメントや本のほとんどを独力で書いている）が書いているもののほとんどです。
私が考えることができる1つのことは
git add .
git commit -am "message"
vs.
hg ci -Am "message"
git commit -aは新しく作成されたファイルを追加しません、hg ci -Aは、gitで2つのコマンドを必要とする処理をMercurialの1つのコマンドで実行できることを意味します。繰り返しになりますが、「タイピングを少なくする」ことは必ずしも「よりユーザーフレンドリー」を意味するわけではありません。