Saya telah menggunakan git untuk beberapa waktu sekarang di Windows (dengan msysGit) dan saya suka ide kontrol sumber terdistribusi. Baru-baru ini saya telah melihat Mercurial (hg) dan itu terlihat menarik. Namun, saya tidak bisa membungkus kepala saya di sekitar perbedaan antara hg dan git.
Adakah yang membuat perbandingan berdampingan antara git dan hg? Saya tertarik untuk mengetahui apa yang membedakan hg dan git tanpa harus berdiskusi dengan penggemar.
Jawaban:
Artikel-artikel ini dapat membantu:
Sunting : Membandingkan Git dan Mercurial dengan selebriti tampaknya menjadi tren. Ini satu lagi:
Saya bekerja pada Mercurial, tetapi pada dasarnya saya percaya kedua sistem itu setara. Keduanya bekerja dengan abstraksi yang sama: serangkaian snapshot (perubahan) yang membentuk sejarah. Setiap changeset tahu dari mana asalnya (parentetsetet) dan dapat memiliki banyak perubahan anak. Perpanjangan hg-git baru -baru ini menyediakan jembatan dua arah antara Mercurial dan Git dan semacam menunjukkan titik ini.
Git memiliki fokus yang kuat pada mutasi grafik sejarah ini (dengan semua konsekuensi yang menyertainya) sedangkan Mercurial tidak mendorong penulisan ulang sejarah, tetapi tetap mudah untuk melakukannya dan konsekuensi dari melakukannya adalah persis seperti yang Anda harapkan dari mereka (yaitu , jika saya memodifikasi set perubahan yang sudah Anda miliki, klien Anda akan melihatnya sebagai baru jika Anda menarik dari saya). Jadi Mercurial memiliki bias terhadap perintah yang tidak merusak.
Adapun cabang ringan, maka Mercurial telah mendukung repositori dengan banyak cabang sejak ..., selalu saya pikir. Repositori Git dengan banyak cabang persis seperti itu: banyak untai pengembangan yang berbeda dalam satu repositori. Git kemudian menambahkan nama ke untaian ini dan memungkinkan Anda untuk menanyakan nama-nama ini dari jarak jauh. The Bookmarks ekstensi untuk Mercurial menambahkan nama lokal, dan dengan Mercurial 1.6, Anda dapat memindahkan bookmark di sekitar ketika Anda mendorong / tarik ..
Saya menggunakan Linux, tetapi ternyata TortoiseHg lebih cepat dan lebih baik daripada yang setara dengan Git di Windows (karena penggunaan sistem file Windows yang buruk). Baik http://github.com dan http://bitbucket.org menyediakan hosting online, layanan di Bitbucket sangat bagus dan responsif (saya belum mencoba github).
Saya memilih Mercurial karena terasa bersih dan elegan - saya tidak menyukai skrip shell / Perl / Ruby yang saya dapatkan dengan Git. Coba intip git-instaweb.shfile tersebut jika Anda ingin tahu apa yang saya maksud: itu adalah skrip shell yang menghasilkan skrip Ruby , yang saya pikir menjalankan server web. Script shell menghasilkan script shell lain untuk meluncurkan script Ruby pertama. Ada juga sedikit Perl , untuk ukuran yang baik.
Saya suka posting blog yang membandingkan Mercurial dan Git dengan James Bond dan MacGyver - Mercurial entah bagaimana lebih rendah daripada Git. Menurut saya, orang yang menggunakan Mercurial tidak mudah terkesan. Ini tercermin dalam bagaimana setiap sistem melakukan apa yang digambarkan Linus sebagai "penggabungan paling keren yang pernah ada!" . Di Git, Anda dapat bergabung dengan repositori yang tidak terkait dengan melakukan:
git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit
Perintah-perintah itu terlihat sangat misterius di mataku. Dalam Mercurial kita lakukan:
hg pull --force <project-to-union-merge>
hg merge
hg commit
Perhatikan bagaimana perintah Mercurial polos dan tidak spesial sama sekali - satu-satunya hal yang tidak biasa adalah --forceflag hg pull, yang diperlukan karena Mercurial akan membatalkan jika tidak ketika Anda menarik dari repositori yang tidak terkait. Perbedaan seperti ini yang membuat Mercurial tampak lebih elegan bagiku.
git pull <url-of-project>. surat yang Anda kutip berasal dari masa-masa awal git (2005)
Git adalah sebuah platform, Mercurial adalah "hanya" aplikasi. Git adalah platform sistem file berversi yang dikirimkan bersama dengan aplikasi DVCS di dalam kotak, tetapi seperti biasa untuk aplikasi platform, Git lebih kompleks dan memiliki tepi yang lebih kasar daripada aplikasi fokus. Tetapi ini juga berarti git's VCS sangat fleksibel, dan ada banyak hal non-sumber-kontrol yang dapat Anda lakukan dengan git.
Itulah inti perbedaannya.
Git paling baik dipahami dari bawah ke atas - dari format repositori ke atas. Scott Chacon's Git Talk adalah yang utama untuk ini. Jika Anda mencoba menggunakan git tanpa mengetahui apa yang terjadi di bawah tenda, pada akhirnya Anda akan bingung (kecuali Anda tetap menggunakan fungsionalitas yang sangat mendasar). Ini mungkin terdengar bodoh ketika semua yang Anda inginkan adalah DVCS untuk rutinitas pemrograman harian Anda, tetapi genius git adalah bahwa format repositori sebenarnya sangat sederhana dan Anda dapat memahami seluruh operasi git dengan cukup mudah.
Untuk beberapa perbandingan yang lebih berorientasi teknis, artikel terbaik yang saya pribadi lihat adalah Dustin Sallings ':
Dia sebenarnya menggunakan kedua DVCS secara ekstensif dan memahami keduanya dengan baik - dan akhirnya lebih memilih git.
Perbedaan besar ada pada Windows. Mercurial didukung secara native, Git tidak. Anda bisa mendapatkan hosting sangat mirip dengan github.com dengan bitbucket.org (sebenarnya lebih baik karena Anda mendapatkan repositori pribadi gratis). Saya menggunakan msysGit untuk sementara waktu tetapi pindah ke Mercurial dan sangat senang dengannya.
Jika Anda adalah pengembang Windows yang mencari kontrol revisi terputus dasar, ikuti Hg. Saya menemukan Git tidak bisa dimengerti sementara Hg sederhana dan terintegrasi dengan baik dengan shell Windows. Saya mengunduh Hg dan mengikuti tutorial ini (hginit.com) - sepuluh menit kemudian saya memiliki repo lokal dan kembali bekerja pada proyek saya.
Saya pikir deskripsi terbaik tentang "Mercurial vs Git" adalah:
"Git adalah Wesley Snipes. Mercurial adalah Denzel Washington"
Mereka hampir identik. Perbedaan paling penting, dari sudut pandang saya (maksud saya, alasan yang membuat saya memilih satu DVCS daripada yang lain) adalah bagaimana kedua program mengelola cabang.
Untuk memulai cabang baru, dengan Mercurial, Anda cukup menyalin repositori ke direktori lain dan mulai mengembangkan. Lalu, Anda tarik dan gabungkan. Dengan git, Anda harus secara eksplisit memberikan nama ke cabang topik baru yang ingin Anda gunakan, lalu mulai coding menggunakan direktori yang sama .
Singkatnya, setiap cabang di Mercurial membutuhkan direktori sendiri; di git Anda biasanya bekerja di direktori tunggal. Berpindah cabang di Mercurial berarti mengubah direktori; di git, itu berarti meminta git untuk mengubah konten direktori dengan checkout git.
Saya jujur: Saya tidak tahu apakah mungkin untuk melakukan hal yang sama dengan Mercurial, tetapi karena saya biasanya bekerja pada proyek web, menggunakan selalu direktori yang sama dengan git tampaknya jauh lebih nyaman bagi saya, karena saya tidak perlu kembali -configurasikan Apache dan mulai kembali dan saya tidak mengacaukan sistem file saya setiap kali saya bercabang.
Sunting: Seperti yang dicatat Deestan, Hg telah menamai cabang , yang dapat disimpan dalam satu repositori dan memungkinkan pengembang untuk berganti cabang dalam copy pekerjaan yang sama. cabang git tidak persis sama dengan cabang bernama Mercurial, pokoknya: mereka permanen dan tidak membuang cabang, seperti di git. Itu berarti bahwa jika Anda menggunakan cabang bernama untuk tugas eksperimental bahkan jika Anda memutuskan untuk tidak pernah menggabungkannya, itu akan disimpan dalam repositori. Itulah alasan mengapa Hg menganjurkan untuk menggunakan klon untuk tugas eksperimental, jangka pendek dan menamai cabang untuk tugas jangka panjang, seperti untuk cabang rilis.
Alasan mengapa banyak pengguna Hg lebih memilih klon daripada cabang bernama jauh lebih sosial atau budaya daripada teknis. Misalnya, dengan versi terakhir Hg, bahkan mungkin untuk menutup cabang bernama dan menghapus metadata dari perubahan secara rekursif.
Di sisi lain, git mengundang untuk menggunakan "cabang bernama" yang tidak permanen dan tidak disimpan sebagai metadata pada setiap perubahan.
Dari sudut pandang pribadi saya, kemudian, model git sangat terkait dengan konsep cabang bernama dan beralih antara cabang dan yang lain dengan direktori yang sama; hg dapat melakukan hal yang sama dengan cabang bernama, tetapi belum mendorong penggunaan klon, yang secara pribadi saya tidak suka terlalu banyak.
Ada satu perbedaan besar antara git dan lincah ; cara masing-masing mewakili komit. git merepresentasikan commit sebagai snapshot, sementara mercurial merepresentasikannya sebagai diffs.
Apa artinya ini dalam praktik? Yah, banyak operasi yang lebih cepat di git, seperti beralih ke komit lain, membandingkan komit, dll. Khususnya jika komit ini jauh.
AFAIK tidak ada keuntungan dari pendekatan lincah.
Tidak ada. Mereka berdua melakukan hal yang sama, keduanya melakukan hal yang sama. Satu-satunya alasan Anda harus memilih satu di antara yang lain adalah jika Anda membantu proyek yang sudah menggunakan satu ..
Alasan lain yang mungkin untuk memilih satu adalah aplikasi atau layanan yang hanya mendukung salah satu sistem .. Misalnya, saya cukup banyak memilih untuk belajar git karena github ..
Juga perbandingan Google (meskipun agak lama, dilakukan pada 2008)
Jika saya memahaminya dengan benar (dan saya jauh dari ahli tentang masing-masing) mereka pada dasarnya masing-masing memiliki filosofi yang berbeda. Saya pertama kali menggunakan lincah selama 9 bulan. Sekarang saya sudah menggunakan git untuk 6.
hg adalah perangkat lunak kontrol versi. Tujuan utamanya adalah melacak versi suatu perangkat lunak.
git adalah sistem file berbasis waktu. Tujuannya adalah untuk menambahkan dimensi lain ke sistem file. Sebagian besar memiliki file dan folder, git menambah waktu. Bahwa itu terjadi untuk bekerja luar biasa sebagai VCS adalah produk sampingan dari desainnya.
Dalam hg, ada sejarah seluruh proyek yang selalu berusaha untuk dipelihara. Secara default, saya yakin hg ingin semua perubahan pada semua objek oleh semua pengguna saat mendorong dan menarik.
Di git hanya ada kumpulan objek dan file pelacakan ini (cabang / kepala) yang menentukan set objek mana yang mewakili pohon file dalam keadaan tertentu. Ketika mendorong atau menarik git hanya mengirimkan objek yang dibutuhkan untuk cabang tertentu yang Anda dorong atau tarik, yang merupakan subset kecil dari semua objek.
Sejauh menyangkut git, tidak ada "1 proyek". Anda dapat memiliki 50 proyek dalam repo dan git yang sama tidak akan peduli. Masing-masing dapat dikelola secara terpisah dalam repo yang sama dan hidup dengan baik.
Konsep cabang Hg adalah cabang dari proyek utama atau cabang dari cabang dll. Git tidak memiliki konsep seperti itu. Cabang di git hanyalah keadaan pohon, semuanya adalah cabang di git. Cabang mana yang resmi, terkini, atau terbaru tidak memiliki arti dalam git.
Saya tidak tahu apakah itu masuk akal. Jika saya bisa menggambar gambar hg mungkin terlihat seperti ini di mana setiap komit adalaho
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
Sebuah pohon dengan satu akar dan ranting keluar darinya. Sementara git dapat melakukan itu dan seringkali orang menggunakannya dengan cara yang tidak diberlakukan. Sebuah gambar git, jika ada hal seperti itu, dapat dengan mudah terlihat seperti ini
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
Bahkan dalam beberapa hal bahkan tidak masuk akal untuk menunjukkan cabang di git.
Satu hal yang sangat membingungkan untuk diskusi, git dan lincah keduanya memiliki sesuatu yang disebut "cabang" tetapi mereka tidak jauh dari hal yang sama. Cabang dalam lincah muncul ketika ada konflik antara repo yang berbeda. Cabang di git tampaknya mirip dengan klon di hg. Tapi klon, sementara itu mungkin memberikan perilaku yang sama pasti tidak sama. Pertimbangkan saya mencoba ini dalam git vs hg menggunakan repo kromium yang agak besar.
$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'
real 0m1.759s
user 0m1.596s
sys 0m0.144s
Dan sekarang di hg menggunakan klon
$ time hg clone project/ some-clone/
updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real 0m58.196s
user 0m19.901s
sys 0m8.957
Keduanya adalah hot run. Yaitu, saya berlari mereka dua kali dan ini adalah lari kedua. klon hg sebenarnya sama dengan git-new-workdir. Keduanya membuat direktori kerja yang sama sekali baru seolah-olah Anda telah mengetikcp -r project project-clone . Itu tidak sama dengan membuat cabang baru di git. Beratnya jauh lebih berat. Jika benar ada yang setara dengan percabangan git di hg, saya tidak tahu apa itu.
Saya mengerti pada tingkat tertentu, hg dan git mungkin dapat melakukan hal serupa. Jika demikian maka masih ada perbedaan besar dalam alur kerja yang mereka arahkan ke Anda. Di git, alur kerja tipikal adalah membuat cabang untuk setiap fitur.
git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support
Itu baru saja membuat 3 cabang, masing-masing berdasarkan dari cabang yang disebut master. (Saya yakin ada beberapa cara di git untuk membuat masing-masing 1 baris itu bukannya 2)
Sekarang untuk mengerjakan yang saya lakukan
git checkout fix-game-save-bug
dan mulai bekerja. Berkomitmen, dll. Beralih antar cabang bahkan dalam proyek sebesar chrome hampir seketika. Sebenarnya saya tidak tahu bagaimana melakukannya di hg. Itu bukan bagian dari tutorial yang saya baca.
Satu perbedaan besar lainnya. Panggung Git.
Git memiliki ide panggung. Anda dapat menganggapnya sebagai folder tersembunyi. Ketika Anda berkomitmen Anda hanya melakukan apa yang ada di atas panggung, bukan perubahan di pohon kerja Anda. Itu mungkin terdengar aneh. Jika Anda ingin mengkomit semua perubahan di pohon kerja Anda, lakukan git commit -ayang menambahkan semua file yang dimodifikasi ke panggung dan kemudian lakukan.
Apa gunanya panggung itu? Anda dapat dengan mudah memisahkan komit Anda. Bayangkan Anda mengedit joypad.cpp dan gamesave.cpp dan Anda ingin mengkomitnya secara terpisah
git add joypad.cpp // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp // copies to stage
git commit -m "fixed game save bug"
Git bahkan memiliki perintah untuk memutuskan baris tertentu dalam file yang sama yang ingin Anda salin ke panggung sehingga Anda dapat membagi komit-komit tersebut secara terpisah. Mengapa Anda ingin melakukan itu? Karena sebagai komitmen terpisah, orang lain hanya dapat menarik yang mereka inginkan atau jika ada masalah, mereka dapat mengembalikan hanya komit yang memiliki masalah.
git add --patch, melihat linux.die.net/man/1/git-add atau penggunaan git add -i, seperti di stackoverflow.com/questions/2372583/...
checkout -b <name>Anda bisa gunakan git branch <name>untuk membuat cabang baru tanpa beralih ke itu
Ada bagan perbandingan dinamis di di versioncontrolblog di mana Anda dapat membandingkan beberapa sistem kontrol versi yang berbeda.
Berikut ini adalah tabel perbandingan antara git, hg dan bzr.
dir-a/foo.cmenjadi dir-b/foo.cdan terus bekerja dir-b/foo.c, maka pekerjaan Anda dir-a/foo.cakan digabung dengan benar dengan pekerjaan saya setelah menarik.
Ada perbedaan yang cukup signifikan dalam hal bekerja dengan cabang (terutama yang jangka pendek).
Hal ini dijelaskan dalam artikel ini (BranchingExplained) yang membandingkan Mercurial dengan Git.
Apakah ada kolaborator berbasis Windows di proyek Anda?
Karena jika ada, GUI Git-for-Windows tampaknya canggung, sulit, tidak ramah.
Sebaliknya, Mercurial-on-Windows adalah no-brainer.
Satu hal yang perlu diperhatikan antara mercurial dari bitbucket.org dan git dari github adalah, mercurial dapat memiliki repositori pribadi sebanyak yang Anda inginkan, tetapi github Anda harus meningkatkan ke akun berbayar. Jadi, itu sebabnya saya menggunakan bitbucket yang menggunakan mercurial.
Suatu waktu tahun lalu saya mengevaluasi git dan hg untuk saya gunakan sendiri, dan memutuskan untuk pergi dengan hg. Saya merasa itu tampak seperti solusi yang lebih bersih, dan bekerja lebih baik pada lebih banyak platform pada saat itu. Tapi sebagian besar adalah undian.
Baru-baru ini, saya mulai menggunakan git karena git-svn dan kemampuan untuk bertindak sebagai klien Subversion. Ini memenangkan saya dan saya sekarang telah beralih sepenuhnya ke git. Saya pikir itu punya kurva belajar yang sedikit lebih tinggi (terutama jika Anda perlu mencari-cari di dalam), tetapi itu benar-benar sistem yang hebat. Saya akan membaca dua artikel perbandingan yang diposting John sekarang.
Saat ini saya sedang dalam proses migrasi dari SVN ke DVCS (saat blogging tentang temuan saya, upaya blogging nyata pertama saya ...), dan saya telah melakukan sedikit riset (= googling). Sejauh yang saya bisa lihat, Anda dapat melakukan sebagian besar hal dengan kedua paket. Sepertinya git memiliki beberapa fitur canggih yang lebih atau lebih baik diimplementasikan, saya merasa bahwa integrasi dengan windows sedikit lebih baik untuk lincah, dengan TortoiseHg. Saya tahu ada Git Cheetah juga (saya mencoba keduanya), tetapi solusi lincah hanya terasa lebih kuat.
Melihat bagaimana mereka berdua open-source (kan?) Saya tidak berpikir keduanya akan kekurangan fitur-fitur penting. Jika sesuatu itu penting, orang akan memintanya, orang akan mengkodekannya.
Saya pikir untuk praktik umum, Git dan Mercurial lebih dari cukup. Mereka berdua memiliki proyek-proyek besar yang menggunakannya (Git -> linux kernel, Mercurial -> proyek yayasan Mozilla, keduanya tentu saja antara lain), jadi saya tidak berpikir keduanya benar-benar kekurangan sesuatu.
Yang sedang berkata, saya tertarik pada apa yang orang lain katakan tentang ini, karena itu akan menjadi sumber yang bagus untuk upaya blog saya ;-)
Ada tabel perbandingan dan grafik perbandingan hebat dan lengkap di git, Mercurial, dan Bazaar di panduan InfoQ tentang DVCS .
Saya menyadari ini bukan bagian dari jawaban, tetapi pada catatan itu, saya juga berpikir ketersediaan plugin stabil untuk platform seperti NetBeans dan Eclipse memainkan bagian di mana alat lebih cocok untuk tugas tersebut, atau lebih tepatnya, alat mana adalah yang paling cocok untuk "kamu". Yaitu, kecuali Anda benar - benar ingin melakukannya dengan cara CLI.
Baik Eclipse (dan semuanya berdasarkan itu) dan NetBeans terkadang memiliki masalah dengan sistem file jarak jauh (seperti SSH) dan pembaruan eksternal file; yang merupakan alasan lain mengapa Anda ingin apa pun yang Anda pilih untuk bekerja "mulus".
Saya mencoba untuk menjawab pertanyaan ini untuk diri saya sendiri sekarang juga .. dan saya sudah menurunkan kandidat untuk Git atau Mercurial .. terima kasih semua untuk memberikan masukan yang berguna pada topik ini tanpa menjadi religius.
Namun perbandingan lain yang menarik antara mercurial dan git: Mercurial vs Git . Fokus utama adalah pada internal dan pengaruhnya terhadap proses percabangan.
Jika Anda tertarik pada perbandingan kinerja Mercurial dan Git, lihat artikel ini . Kesimpulannya adalah:
Git dan Mercurial keduanya menghasilkan angka yang baik tetapi membuat trade-off yang menarik antara kecepatan dan ukuran repositori. Mercurial cepat dengan penambahan dan modifikasi, dan menjaga pertumbuhan repositori tetap terkendali secara bersamaan. Git juga cepat, tetapi repositori tumbuh sangat cepat dengan file yang dimodifikasi hingga Anda mengemasnya kembali - dan repack itu bisa sangat lambat. Tetapi repositori yang dikemas jauh lebih kecil daripada milik Mercurial.
Situs web lincah memiliki deskripsi yang bagus tentang persamaan dan perbedaan antara kedua sistem, menjelaskan perbedaan kosakata dan konsep yang mendasarinya. Sebagai pengguna lama git, itu sangat membantu saya memahami pola pikir Mercurial.
Jika Anda bermigrasi dari SVN, gunakan Mercurial karena sintaksnya JAUH lebih mudah dipahami oleh pengguna SVN. Selain itu, Anda juga tidak bisa salah. Tetapi periksa tutorial GIT dan HGinit sebelum memilih salah satunya.
Tautan ini dapat membantu Anda memahami perbedaan http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
Beberapa orang berpikir bahwa sistem VCS harus rumit. Mereka mendorong menciptakan istilah dan konsep di lapangan. Mereka mungkin akan berpikir bahwa banyak PhD pada subjek akan menarik. Di antara mereka mungkin adalah orang-orang yang merancang Git.
Mercurial dirancang dengan mental yang berbeda. Pengembang seharusnya tidak terlalu peduli tentang VCS, dan mereka seharusnya menghabiskan waktu mereka pada fungsi utama mereka: rekayasa perangkat lunak. Mercurial memungkinkan pengguna untuk menggunakan dan dengan senang hati menyalahgunakan sistem tanpa membiarkan mereka melakukan kesalahan yang tidak dapat dipulihkan.
Alat profesional apa pun harus dilengkapi dengan CLI yang dirancang dengan jelas dan intuitif. Pengguna Mercurial dapat melakukan sebagian besar pekerjaan dengan mengeluarkan perintah sederhana tanpa opsi aneh. Di Git double dash, opsi gila adalah normanya. Mercurial memiliki keuntungan substansial jika Anda adalah orang CLI (dan sejujurnya, setiap Insinyur Perangkat Lunak yang menghargai diri sendiri seharusnya).
Untuk memberi contoh, misalkan Anda melakukan komit karena kesalahan. Anda lupa mengedit beberapa file. Untuk membatalkan tindakan Anda di Mercurial Anda cukup mengetik:
$ hg rollback
Anda kemudian mendapatkan pesan bahwa sistem membatalkan transaksi terakhir Anda.
Di Git Anda harus mengetik:
$ git reset --soft HEAD^
Jadi ok kira Anda memiliki ide tentang reset. Tetapi selain itu Anda harus tahu apa yang me-reset "--soft" dan "--hard" (ada tebakan intuitif?). Oh dan tentu saja jangan lupa karakter '^' pada akhirnya! (Sekarang apa nama Ritchie itu ...)
Integrasi Mercurial dengan alat pihak ke-3 seperti kdiff3 dan berbaur jauh lebih baik juga. Hasilkan tambalan Anda menggabungkan cabang-cabang Anda tanpa banyak rewel. Mercurial juga menyertakan server http sederhana yang Anda aktifkan dengan mengetik
hg serve
Dan biarkan orang lain menelusuri repositori Anda.
Intinya adalah, Git melakukan apa yang Mercurial lakukan, dengan cara yang jauh lebih rumit dan dengan CLI yang jauh lebih rendah. Gunakan Git jika Anda ingin mengubah VCS proyek Anda menjadi bidang penelitian ilmiah. Gunakan Mercurial jika Anda ingin menyelesaikan pekerjaan VCS tanpa peduli, dan fokus pada tugas Anda yang sebenarnya.