比較を見ると、機能セット間に1対1のマッピングが存在する可能性があるように思われます。しかし、よく引用される声明は、「Mercurialの方が簡単だ」というものです。この声明の根拠は何ですか?(もしあれば)
比較を見ると、機能セット間に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
Mercurialバージョン:
authors.convert.listファイル:
<oldname>=<newname>
コマンドライン:
hg convert --authors authors.convert.list SOURCE DEST
さて、どちらが使いやすいと思いますか?
注:私はGitだけで2年間働いていたので、これは「嫌い、2秒で手に入らなかった」という暴言ではありません。
私にとっては、使いやすさです。Gitは非常にLinux指向であり、Linuxの方法を使用しています。つまり、コマンドライン、マニュアルページ、および自分で理解することです。GUIが非常に貧弱でした(注:約1年前からこれをmsysGitに基づいています)。かろうじて使用できた
コマンドラインはさらに悪かった。Linux指向のプログラムであるため、Windowsでは使用が非常に困難でした。ネイティブポートの代わりに、MinGW(Think cygwin)でgitを単純にラップしたため、Gitでの作業がはるかに困難になりました。MinGWはWindowsコマンドプロンプトではなく、異なる動作をします。これがGitを使用する唯一の方法であることに夢中です。Linuxでさえ、まっすぐなコマンドラインで作業することが唯一の方法のように思えました。RabbitVCSのようなプロジェクトは一部を助けましたが、あまり強力ではありませんでした。
コマンドライン指向のアプローチとLinuxプログラムであるため、ほとんどすべてのハウツーガイド、ヘルプドキュメント、フォーラム/ QAの質問は上記のような巨大なコマンドの実行に依存していました。基本的なSCMコマンド(コミット、プル、プッシュ)はそれほど複雑ではありませんが、それ以上に複雑さが指数関数的に増大します。
また、多くのOSS gitユーザーがうろうろしている1つの場所、Githubも嫌いです。最初にgithubページにアクセスすると、できることは何でもできます。私にとって、プロジェクトのgitページは混oticとしていて恐ろしく、非常に強力に見えます。プロジェクトが何であるかの説明でさえ、下に押し下げられます。Githubは、完全なWebサイトが既にセットアップされていない人々を本当に傷つけます。その問題トラッカーもひどくて混乱しています。機能のオーバーロード。
Gitユーザーも非常にカルト的なようです。Gitユーザーは、常にDVCSの方が優れている「聖戦」を開始するユーザーであるように思われます。これにより、Mercurialユーザーは自己防衛を余儀なくされます。http://whygitisbetterthanx.com/のようなサイトは、ar慢さとほぼ「私のソフトウェアを使うか死ぬか」という考え方を示しています。多くの場合、Xを知らない、Xを事前に使用する、Windowsを使用するなどの理由でflame折するために、さまざまな支援の場所に行ってきました。
一方、Mercurialはより親切なアプローチに向かっているようです。彼らのホームページは、Gitのページよりも新しいユーザーにとってはるかに友好的です。単純なGoogle検索では、5番目の結果はTortoiseHgで、Mercurialの非常に優れたGUIです。彼らの全体的なアプローチは、最初はシンプルで、後は力になるようです。
Mercurialでは、SSHナンセンスはありません(WindowsではSSHは地獄です)、愚かな複雑なコマンドはありません。カルトユーザーはいません。Mercurialは機能します。
TortoiseHgは、実際に有用な機能を提供する実際に使用可能なインターフェースを提供します(最近は成長しているようですが)。オプションは必要なものに限定され、めったに使用されない混乱とオプションを取り除きます。また、多くの適切なデフォルトを提供します
Mercurialは、新規参入者に非常に親しみやすく、簡単に手に入れることができました。さまざまな分岐モデルや履歴編集など、より複雑なトピックのいくつかでも非常に簡単に理解できました。私はMercurialを迅速かつ無痛で手に入れました。
Mercurialは、セットアップがほとんどなくても初めて動作します。どのOSでも、TortoiseHgをインストールするだけで、さまざまなGuisを探す必要なく、必要なすべての機能(主にコンテキストメニューコマンド)を取得できます。また、SSHのセットアップもありません(ガイドの半分はPutty、Plink、およびPagentを使用すると言い、残りの半分はssh-keygenを使用すると言っています)。新規ユーザーの場合、TortoiseHgのセットアップには数分かかりますが、Gitは多くのグーグルで30分から1時間かかります。
最後に、オンラインリポジトリがあります。Githubに相当するのはBitBucketで、これには上記で説明した問題がいくつかあります。ただし、Google Codeもあります。Google Codeプロジェクトにアクセスすると、機能のオーバーロードは発生せず、すっきりしたきれいなインターフェイスが表示されます。Google Codeは、オンラインリポジトリ/ウェブサイトのコンボのようなもので、既存のサイト設定がないOSSプロジェクトに本当に役立ちます。私は、かなり長い間、Google CodeをプロジェクトのWebサイトとして使用することに非常に満足し、絶対に必要な場合にのみWebサイトを構築します。その問題トラッカーも強力で、Githubのほとんど役に立たない問題トラッカーとBugzillaの怪物の間にうまく収まります。
Mercurialは、毎回初めて動作します。Gitは邪魔になり、使用するほど怒ります。
Mercurialは一般に、Gitよりも簡単で習得しやすいと考えられています。同様に、Gitはより柔軟で強力であるという認識がしばしばあります。これは、一部にはGitがより低レベルのコマンドを提供する傾向があるためですが、一部にはデフォルトのMercurial が高度な機能を非表示にする傾向があり、ユーザーが希望する高度な機能をアクティブにするために水銀設定ファイルを編集できるようにするためです。多くの場合、これはMercurialでは高度な機能を利用できないという認識につながります。
Mercurialは常にインターフェースの側面に重点を置いてきたため、元々学習が容易になりました。Gitと比較して、Mercurialを便利な方法で操作するには、より浅い理解が必要です。長い目で見れば、このようなカプセル化は、Mercurialに実際よりも強力で機能性が低いという誤った外観を与えています。
~
にはrevsetsがあります。ステージング領域はありませんが、MQを使用してエミュレートできます。MQは非常に強力です。gitから知っていることにこだわるのではなく、このツールを使用する方法を学んでください。
hg push --branch BRANCH
)または特定のリビジョン(hg push --rev REV
)までプッシュできます。hg help push
その他のオプションについてはご覧ください。
コンテキスト:Mercurial(仕事用)とGit(サイドプロジェクトおよびオープンソース用)の両方を毎日使用しています。私は主に(IDEではなく)両方でテキストベースのツールを使用し、Macを使用しています。
一般に、Mercurialの方が使いやすいと感じています。私が見つけたいくつかのことがMercurialを簡単にします。
hg
同等のgit
分岐が実際に呼び出されbookmarks
。私の知る限り、hg
ブランチにはに相当するものがありませんgit
。
git
は、分岐は分岐のサブセットですhg
。ではhg
、あなたの両方の名前と名前なし(位相幾何学)の支店を持つことができ、さらに同じように、名前の枝を管理できるgit
ブックマークを使用。ステージングエリアのポイントを見たことはありません。むしろ不要な変更を棚上げしてから、コミットする前にコードがテストをコンパイルして完了することを確認します。その後、シェルフを解除して続行できます。また、チャールズベイリーの「マッサージハンク」(p90 +)は私を怖がらせます* 8 '):accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
hg bookmark keyo-stuff
行いhg commit
、最終的にhg push -B keyo-stuff
。リビジョン番号が気に入らない場合は、使用しないでください。Mercurialは、リビジョン番号を受け入れる場所であればどこでもハッシュを受け入れます。実際、Mercurialの機能が不足しているためにMercurialを攻撃しているというコメントは、無知で少し攻撃的であると感じています。あなたはGitユーザーのステレオタイプに対してあまり良いことをしていません!
これは非常に主観的なものであり、人によって異なりますが、はい、VCSがまったく新しい人や「古い学校」のVCSから来た人には、Mercurialの方が簡単だと思います。
たとえば、ファイルを追加する、Hgにインデックスが存在しない、いくつかの最も「明白な」例として、古いリビジョンに戻ってそこから分岐する(更新およびコミットする)だけの簡単さ。現在、1つのシステムのほとんどの機能を別のシステムでエミュレートできますが、Gitである程度の知識が必要ですが、Mercurialではデフォルト(ユーザーに呼び出しを許可する場合)はかなり「ユーザーフレンドリー」です。これらのささいなこと-あちこちのスイッチ、1つのコマンドでの非自明な動作など...これらのことは重なり合い、最終的に、1つのシステムが他のシステムよりも使いやすいように見えます。
答えを完成させるだけです。私はgitを使用していますが、「初めて」の人にVCSを勧めるときは、ほとんど常にMercurialをお勧めします。私が覚えているのは、それが最初に手に入ったとき、非常に直感的だったと感じたことです。私の経験では、MercurialはGitよりも少ないwtf /分を生成します。
私はそれはこれと同じくらい簡単だと思います:Mercurialは(特にSVNユーザーにとって)より馴染みのある構文を持ち、かなりよく文書化されています。Git構文に慣れると、他のGit構文と同じくらい簡単に使用できます。
これに関して、認識は時間とともに変化する可能性があります。Mercurialは非常にうまく設計されており、Gitも同様です。Mercurialは習得しやすいように思われます(少なくとも私にとってはそうでした)。Gitで遭遇した困難、Mercurialでの類似点はありませんでした。私はPythonとRubyを学ぼうとしましたが、Pythonでさらに速く、速くなりました。だからといって、Pythonが常にどこでもRubyより優れているというわけではなく、私にとっても優れているというわけでもありません。それは私が学んだこと、そして行き詰まったことです。プログラマーはしばしば個人的な好みから聖戦を行います。他の人間もそうしています。
私はGitについてオープンな心を保とうとする水銀ユーザーであり、Mercurialほどには「私の新しいお気に入りにならない」ことを自由に認めています。Gitは本当に素晴らしいと思います。
GIT / mercurialの複雑さの反例:素晴らしいGITサポートがMacのXCodeに組み込まれています。GITよりもMercurialでのXCodeの使用は簡単ではありません。
GITでのこれまでの経験では、混乱して迷子になり、使用中にドキュメントを参照する必要がありました。私は多くのドキュメントが書かれたと信じていますが、それを「グロッキング」することを可能にしたものは何もありません。第二に、PythonでMercurialを簡単に変更および拡張できます。Pythonに精通しているので、誰でも実際にPythonをすばやく学ぶことができるので、それは私にとって利点のようです。私もCを知っており、CでPython拡張機能を作成しているので、いつか必要になったら、CでGit拡張機能を簡単に作成できると思います。
使いやすさは、簡単に定量化できるものではありません。それはそこにあり、私はそれが完全に主観的であるとは思わないが、我々は良い客観的な測定技術を持っていません。使いやすさの単位は何ですか?Milli-iPods?
私は100%プロ水銀であり、100%反gitであるほど党派ではありません。私は現在、Mercurial、Windows、およびLinuxに慣れており、さらにMacの作業を開始するときには、XCode + GITに固執することを期待しています。
更新2013: MercurialとGITを使用して、マージ戦略に関するこの質問など、Gitに必要な機能を見つけられるようになりました。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 add .
git commit -am "message"
対
hg ci -Am "message"
git commit -a
は、新しく作成されたファイルを追加しませんhg ci -A
。これは、Gitで2つのコマンドを必要とする何かをMercurialの1つのコマンドで実行できることを意味します。繰り返しますが、「タイピングが少ない」とは、必ずしも「よりユーザーフレンドリー」という意味ではありません。
git commit -a
特定のコミットで追加されるものとされないものを簡単に制御できるため、単純に機能する方法を好むようになりました。(実際にはsvn ci
、コミットに無関係な内容を追加しないように、個々のパス名を指定することは私にとって珍しいことではありません。)
hg ci
が、-A
フラグなしではに相当すると思いますgit commit -a
。私はgitをhgよりもずっと多く使用しているので、100%確信はありません。
hg ci
== git commit -a
。
その理由は。
Gitは、水銀よりもはるかに内臓を露出します。Mercurialを拾ってから数分以内に喜んで使用できますが、Gitを2か月間苦労して取り組むのはまだ難しいと思います)。私はコマンドラインからも、主にLinux上でも両方を使用しているので、これはコマンドラインインターフェイスに対する単なる嫌悪ではありません。
1つの簡単な例は、gitと比較してMercurialに必要なフラグとコマンドライン引数が比較的少ないことです。ステージング領域とgitのaddコマンドの動作により、必要以上に複雑さが増します。リセット、チェックアウト、復帰、およびそれらの複数の順列のトリオにより、非常に複雑になります。
Hginitについての上記のコメントにも同意します。水銀が間違いなく理解しやすくなりました。よく書かれており、非常に理解しやすい。git用に書かれたドキュメントはどれも近づいていません。私にとっては、Scott Chacone(Gitに関するドキュメント/書籍のほとんどを独力で書いた)によって書かれた内容のほとんどが特に混乱していることに気づきました。