Mengapa Mercurial dianggap lebih mudah daripada Git?


204

Saat melihat perbandingan, menurut saya mungkin ada pemetaan 1: 1 antara set fitur mereka. Namun, pernyataan yang sering dikutip adalah bahwa "Mercurial lebih mudah". Apa dasar dari pernyataan ini? (jika ada)


21
Aneh, saya tidak pernah mendengar Mercurial lebih mudah. Saya menemukan lebih banyak dokumentasi untuk Git (mungkin persepsi) jadi saya mempelajarinya.
Nic

16
Karena itu dibuat oleh Linus?
Pekerjaan

124
Melangkah ke wilayah perang suci di sini, tetapi saya menemukan Mercurial lebih mudah digunakan daripada Git karena, sebagai pengguna Windows, saya merasa disambut oleh Mercurial, dan diperlakukan seperti orang aneh dan pecundang oleh Git. Saya tahu saya adalah perangkat lunak antropomorfisasi, dan saya tahu bahwa keduanya benar-benar mampu digunakan dengan baik di bawah Windows, tapi itulah kesan yang diberikan oleh mereka berdua.
Carson63000


11
Saya bertanya-tanya berapa banyak orang yang akan menggunakan Git jika Github tidak ada, atau tidak memiliki begitu banyak proyek terkenal di dalamnya?
Chris S

Jawaban:


240

Contoh kasus: Katakanlah Anda ingin mengubah nama pengguna pada semua komitmen Anda sebelumnya. Saya perlu melakukan ini beberapa kali karena berbagai alasan.

Versi 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

Versi Mercurial:

file author.convert.list:

<oldname>=<newname>

Garis komando:

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

Sekarang, mana yang terlihat lebih mudah digunakan?


Catatan: Saya menghabiskan 2 tahun bekerja hanya dengan Git, jadi ini bukan "Aku benci itu, saya tidak mendapatkannya dalam 2 detik" kata-kata kasar.

Bagi saya, ini kegunaannya. Git sangat berorientasi pada linux dengan cara linux dalam melakukan sesuatu. Itu berarti baris perintah, halaman manual, dan mencari tahu sendiri. Itu GUI yang sangat buruk (catatan: Saya mendasarkan ini dari msysGit dari sekitar setahun yang lalu), yang sepertinya hanya menghalangi saya. Saya hampir tidak bisa menggunakannya

Baris perintah lebih buruk. Menjadi program yang berorientasi Linux, pada Windows itu sangat sulit digunakan. Alih-alih port asli mereka hanya membungkus git dengan MinGW (Think cygwin), yang membuatnya bekerja jauh lebih sulit. MinGW bukan Windows Command Prompt, dan hanya bertindak berbeda. Sangat gila bahwa ini adalah satu-satunya cara untuk bekerja dengan Git. Bahkan di Linux sepertinya satu-satunya cara adalah bekerja dengan baris perintah lurus. Proyek seperti RabbitVCS membantu beberapa, tetapi tidak terlalu kuat.

Pendekatan berorientasi baris perintah dan menjadi program linux berarti bahwa hampir semua panduan howto, dokumentasi bantuan, dan pertanyaan forum / QA bergantung pada menjalankan perintah mengerikan seperti di atas. Perintah-perintah SCM dasar (komit, tarik, dorong) tidak serumit itu, tetapi kompleksitas dan kompleksitas tumbuh secara eksponensial.

Saya juga membenci satu tempat yang banyak pengguna OSS git nongkrong: Github. Ketika Anda pertama kali pergi ke halaman github, itu membanting Anda dengan semua yang Anda bisa lakukan. Bagi saya, halaman proyek git terlihat kacau, menyeramkan, dan terlalu kuat. Bahkan penjelasan tentang apa proyek itu, didorong ke bawah. Github benar-benar menyakiti orang yang tidak memiliki situs web lengkap yang sudah disiapkan. Pelacak masalahnya juga mengerikan dan membingungkan. Kelebihan fitur.

Pengguna Git juga sepertinya sangat pemuja. Pengguna Git tampaknya selalu menjadi orang-orang yang memulai "perang suci" di mana DVCS lebih baik, yang kemudian memaksa pengguna Mercurial untuk mempertahankan diri. Situs- situs seperti http://whygitisbetterthanx.com/ menunjukkan arogansi dan mentalitas "Gunakan perangkat lunak atau mati" saya hampir. Banyak kali saya pergi ke berbagai tempat bantuan hanya untuk dinyalakan karena tidak mengetahui X, menggunakan X sebelumnya, menggunakan Windows, dll. Ini gila.


Di sisi lain, lincah tampaknya mengarah pada pendekatan yang lebih baik. Halaman beranda mereka sendiri tampaknya jauh lebih ramah bagi pengguna baru daripada Git . Dalam pencarian Google sederhana hasil ke-5 adalah TortoiseHg, GUI yang sangat bagus untuk Mercurial. Seluruh pendekatan mereka tampaknya kesederhanaan dulu, kekuatan kemudian.

Dengan Mercurial, saya tidak memiliki omong kosong SSH (SSH adalah neraka di Windows), saya tidak memiliki perintah yang rumit, saya tidak memiliki pengikut yang mengikuti, saya tidak memiliki kegilaan. Mercurial hanya berfungsi.

TortoiseHg menyediakan antarmuka yang sebenarnya dapat digunakan (meskipun belakangan ini tampaknya semakin berkembang) yang menyediakan fitur yang sebenarnya berguna. Opsi terbatas pada apa yang Anda butuhkan, menghilangkan kekacauan dan opsi yang jarang digunakan. Ini juga menyediakan banyak default yang layak

Mercurial, karena sangat bersahabat dengan pendatang baru, sangat mudah dijemput. Bahkan beberapa topik yang lebih kompleks seperti model percabangan yang berbeda dan pengeditan sejarah sangat mudah diikuti. Saya mengambil Mercurial dengan cepat dan tanpa rasa sakit.

Mercurial juga hanya berfungsi pertama kali dengan sedikit pengaturan. Pada OS APA PUN saya hanya bisa menginstal TortoiseHg dan mendapatkan semua fitur yang saya inginkan (terutama perintah menu konteks) tanpa harus mencari Guis yang berbeda. Yang juga hilang adalah pengaturan SSH (separuh dari panduan di luar sana mengatakan untuk menggunakan Putty, Plink, dan Pagent sementara separuh lainnya mengatakan menggunakan ssh-keygen). Untuk pengguna baru, TortoiseHg membutuhkan waktu beberapa menit untuk mensetup sementara Git membutuhkan waktu 30 menit hingga satu jam dengan banyak googling.

Terakhir Anda memiliki repo online. Setara dengan Githubs adalah BitBucket, yang memiliki beberapa masalah yang saya uraikan di atas. Namun ada juga Google Code. Ketika saya pergi ke proyek Google Code , saya tidak mendapatkan kelebihan fitur, saya mendapatkan antarmuka yang bagus dan bersih. Google Code lebih merupakan kombo repo / situs web online, yang sangat membantu proyek OSS yang tidak memiliki pengaturan situs yang ada. Saya akan merasa sangat nyaman menggunakan Google Code sebagai situs web proyek saya selama beberapa waktu, hanya membangun situs web ketika benar-benar diperlukan. Pelacak masalahnya juga sangat kuat, cocok dengan baik di antara Pelacak Isu Github yang hampir tidak berguna dan keburukan Bugzilla .

Mercurial hanya berfungsi, pertama kali, setiap kali. Git menghalangi saya dan hanya membuat saya marah semakin saya menggunakannya.


6
Komentator: komentar dimaksudkan untuk mencari klarifikasi, bukan untuk diskusi panjang. Jika Anda punya solusi, tinggalkan jawaban. Jika solusi Anda sudah diposting, harap perbarui. Jika Anda ingin mendiskusikan pertanyaan ini dengan orang lain, silakan gunakan obrolan . Lihat FAQ untuk informasi lebih lanjut.

1
IntelliJ IDEA dan Xcode 4 memiliki integrasi hebat dengan Git pada platform masing-masing dan untuk tugas sehari-hari Anda tidak perlu menggunakan baris perintah.

4
Saya ingin menambahkan bahwa tortoiseGIT jauh lebih baik sekarang ketika Anda ingin menggunakan GIT di windows. Anda masih harus berurusan dengan kunci SSL dan proses instalasi tidak mulus, tetapi ketika selesai bekerja dengan mudah.
Arkh

2
Git Extensions Secara pribadi saya menemukan lebih mudah dinavigasi dan bekerja daripada TortoiseHG di windows, dan saya hanya menggunakan 1 baris perintah dengan git.
KallDrexx

1
Saya agak bingung dengan baris ini: "MinGW bukan Windows Command Prompt, dan hanya bertindak berbeda. Sungguh gila bahwa ini adalah satu-satunya cara untuk bekerja dengan Git." Saya menggunakan instalasi msysgit dan opsi 2, untuk menjalankan dari baris perintah Windows. Ini bekerja dengan baik. Ada beberapa hal yang tidak berfungsi (seperti tanda sisipan, karakter garis-kelanjutan dalam DOS) tetapi ada alternatif untuk itu (seperti tilde) yang berfungsi dengan baik. Saya bukan penggemar baris perintah (atau setidaknya saya tidak sebelum saya mulai belajar Git) tetapi menggunakan Git dengan baris perintah sangat mudah. Apakah saya melewatkan sesuatu?
Kyralessa

80

Git versus Mercurial

Mercurial umumnya diyakini lebih sederhana dan lebih mudah dipelajari daripada Git. Pada gilirannya, sering kali ada persepsi bahwa Git lebih fleksibel dan kuat. Hal ini disebabkan, sebagian, karena Git cenderung memberikan lebih banyak perintah tingkat rendah, tetapi juga sebagian karena Mercurial default cenderung menyembunyikan fitur-fitur canggih , membiarkannya bagi pengguna untuk mengedit file konfigurasi mercurial untuk mengaktifkan fitur-fitur canggih yang mereka sukai. Ini sering mengarah pada persepsi bahwa fitur-fitur canggih tidak tersedia di Mercurial.

Konsep Git

Mercurial selalu lebih fokus pada aspek antarmuka, yang membuatnya lebih mudah dipelajari. Dibandingkan dengan Git, pemahaman yang lebih dangkal diperlukan untuk beroperasi dengan Mercurial dengan cara yang bermanfaat. Dalam jangka panjang, enkapsulasi semacam itu telah membuat Mercurial memiliki penampilan yang salah karena kurang kuat dan penuh fitur daripada sebenarnya.


73
Jadi Mercurial hanya menyembunyikan fungsionalitas canggih, sementara GIT menyembunyikan semua fungsionalitas ... ;-)
awe

4
Git memang memiliki kekuatan lebih. Misalnya tidak ada yang setara dengan KEPALA git ~ 1 . Mercurial memiliki p (x) yang membentang melintasi cabang, betapa tidak berguna. Tidak ada panggung di Hg. Semua cabang harus didorong ketika Anda mendorong. Mercurial tidak fleksibel, bahkan dengan semua plugin seperti histedit, rak, dan rebase. Baris perintah Git juga lebih baik, ini memberikan petunjuk kepada pengguna, Mercurial tidak. Saya terpaksa menggunakan DVCS yang sedikit cacat ini di tempat kerja dan saya telah memasuki situasi di mana lincah tidak memiliki kekuatan untuk melakukan apa yang saya inginkan.
Keyo

22
@Keyo: Mercurial punya ~, lihat revsets . Itu tidak memiliki area pementasan, tetapi Anda dapat meniru dengan MQ, yang jauh lebih kuat. Belajarlah untuk menggunakan alat ini daripada berpegang pada apa yang Anda ketahui dari git, itu akan membuahkan hasil.
Idan K

22
@Keyo: Anda tidak perlu mendorong semua cabang dengan Mercurial saat Anda mendorong. Anda dapat mendorong cabang tertentu ( hg push --branch BRANCH) atau ke revisi tertentu ( hg push --rev REV). Silakan lihat hg help pushopsi lainnya.
Bupati

1
FYI, seseorang bisa mendapatkan subset yang cukup besar dari area pementasan menggunakan ekstensi catatan . OTOH, saya pikir ekstensi rak (model setelah "rak" perintah dari Baazar, dan dekat dengan "git simpanan") melayani sebagian besar tujuan penggunaan area pementasan.
brandizzi

47

Konteks: Saya menggunakan Mercurial (untuk pekerjaan) dan Git (untuk proyek sampingan dan open source) setiap hari. Saya terutama menggunakan alat berbasis teks dengan keduanya (bukan IDE) dan saya menggunakan Mac.

Secara umum, saya menemukan Mercurial lebih mudah untuk dikerjakan. Beberapa hal yang saya temukan membuat Mercurial lebih mudah:

  1. Kurangnya indeks. Indeks adalah alat yang ampuh yang memungkinkan banyak fitur Git tetapi juga lapisan tambahan yang menambahkan langkah ke banyak hal yang saya lakukan secara teratur. Alur kerja Mercurial lebih mirip dengan sesuatu seperti svn.
  2. Revisi angka alih-alih shas. Ini adalah hal kecil yang saya temukan membuat bekerja dengan perintah setiap hari jauh lebih mudah di Mercurial. Jauh lebih mudah untuk mendorong beberapa angka revisi ke kepala Anda selama rebase, penggabungan, dll saat menulis perintah daripada melakukan hal yang sama dengan shas yang bahkan lebih pendek.
  3. Ranting. Pendekatan Git terhadap cabang dengan menamai commit sangat kuat dan secara substansial berbeda dari sistem kontrol versi lainnya. Itu membuat hal-hal tertentu jauh lebih mudah. Saya menemukan bahwa pendekatan Mercurial cocok dengan pemikiran yang sedikit lebih baik dan membuatnya lebih mudah untuk secara visual memahami sejarah cabang. Ini mungkin hanya preferensi.

6
+1 untuk menyebutkan indeks; Saya pikir indeks dan interaksinya adalah yang hal yang membuat git lebih sulit untuk belajar dari lincah.
Sean McMillan

18
The hgsetara dengan gitcabang-cabang yang benar-benar disebut bookmarks. Sejauh yang saya tahu, hgcabang tidak memiliki yang setara di git.
Hank Gay

6
Saya dalam situasi yang sama, dengan lincah di tempat kerja dan git di rumah. Percabangan raksa agak mengganggu bagi saya, saya suka memiliki cabang pribadi dan mendorong mereka ketika saya mau. Mercurial memaksa saya untuk menggunakan rak atau repo tambahan. Angka revisi konyol, beri saya hash. Panggungnya bagus di git, aku rindu ini. Saya benar-benar kehilangan kekuatan git. Saya melakukan beberapa hal dengan beberapa plugin tetapi percabangan benar-benar mengganggu saya.
Keyo

6
@Keyo - Menurut pengalaman saya, gitpercabangan adalah bagian dari hgpercabangan. Di dalam hgAnda dapat memiliki cabang bernama dan tanpa nama (topologi), dan bahkan dapat mengelola cabang tanpa nama dengan cara yang sama seperti gitmenggunakan bookmark. Saya belum pernah benar-benar melihat titik di area pementasan. Saya lebih suka menyimpan perubahan yang tidak diinginkan dan kemudian memastikan bahwa kode saya mengkompilasi & menyelesaikan tes saya sebelum melakukan itu. Saya kemudian bisa mengesampingkan dan melanjutkan. Juga, "Massaging Hunks" Charles Bailey (p90 +) membuatku takut * 8 '): accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
Mark Booth

7
@Keyo: Dalam Mercurial, cabang pribadi disebut 'bookmark': perbarui ke revisi root hg bookmark keyo-stuff,, lakukan sesuatu hg commit,, kemudian pada akhirnya hg push -B keyo-stuff. Jika Anda tidak suka angka revisi, jangan gunakan; Mercurial akan menerima hash di mana saja ia akan menerima nomor revisi, saya pikir. Saya harus mengatakan, komentar Anda bashing Mercurial karena kurangnya fitur yang sebenarnya dianggap sebagai bodoh dan sedikit agresif; Anda tidak melakukan banyak hal baik untuk stereotip pengguna Git!
Tom Anderson

29

Ini sangat subyektif dan tergantung dari satu orang ke orang lain, tetapi ya, saya akan mengatakan bahwa kepada seseorang yang sama sekali baru untuk VCS atau seseorang yang berasal dari salah satu VCS "sekolah lama", Mercurial akan tampak lebih mudah.

Misalnya, menambahkan file, tidak adanya indeks dalam Hg, kemudahan untuk kembali ke beberapa revisi lama dan bercabang dari sana (cukup perbarui dan komit) sebagai beberapa contoh yang paling "jelas". Sekarang sebagian besar fitur dari satu sistem dapat ditiru di sistem lain dan sebaliknya, tetapi itu membutuhkan pengetahuan di Git, sementara di Mercurial default-nya (jika Anda mengizinkan saya memanggilnya) agak "ramah pengguna". Hal-hal kecil itu - sakelar di sana-sini, perilaku yang tidak jelas dalam satu perintah dan seterusnya ... hal-hal ini bertambah, dan pada akhirnya, satu sistem tampaknya lebih mudah digunakan daripada yang lain.

Hanya untuk membuat jawabannya lengkap; Saya menggunakan git, tetapi ketika merekomendasikan VCS untuk seseorang yang "baru bagi mereka", saya hampir selalu merekomendasikan Mercurial. Saya ingat, ketika pertama kali masuk ke tangan saya, rasanya sangat intuitif. Ini adalah pengalaman saya bahwa Mercurial menghasilkan lebih sedikit wtf / menit dari Git.


+1 untuk "kurang wtf / menit" -1 untuk "ini sangat subjektif". Itu tidak terlalu subyektif ... Saya tidak tahu mengapa orang masih berpikir bahwa perbedaan UI itu subyektif. Jika saya mengambil perintah lincah dan hash md5, Anda tidak akan membuat argumen bahwa beberapa orang mungkin menemukan hash md5 lebih intuitif daripada yang asli, bukan? (Saya harap tidak). Hal yang sama berlaku untuk Git. Git hanya lebih mudah daripada lincah jika pengalaman Anda dengan git jauh lebih penting daripada lincah.
weberc2

17

Saya pikir ini sesederhana ini: Mercurial memiliki sintaks yang lebih akrab (terutama untuk pengguna SVN) dan didokumentasikan dengan cukup baik. Setelah Anda terbiasa dengan sintaks Git, Anda akan merasa mudah digunakan seperti yang lainnya.


7
Nggak. Ada terlalu banyak langkah alur kerja bagi Anda untuk menyebutnya hanya "sintaks yang berbeda". Anda harus memahami model dasar yang Anda manipulasi, dan semua status indeks git, untuk menggunakan Git. Mengatakan SQL dan Pascal adalah dua sintaks yang berbeda untuk hal yang sama akan sama salahnya. Git adalah sistem versi-file-sistem-konten dengan fitur DVCS. Mercurial adalah DVCS yang tidak melakukan setiap operasi GIT versi sistem file-sistem-konten, hanya bagian yang diperlukan semua pengguna DVCS.
Warren P

9

Persepsi mungkin berubah seiring waktu, dalam hal ini. Mercurial dirancang dengan sangat baik, dan begitu pula Git. Mercurial tampaknya lebih mudah dipelajari (setidaknya bagi saya), dan ada kesulitan yang saya temui di Git, yang tidak saya miliki paralelnya dengan Mercurial. Saya mencoba mempelajari Python, dan Ruby, dan semakin jauh, lebih cepat dengan Python. Itu tidak berarti Python selalu dan di mana-mana lebih baik daripada Ruby, atau bahkan lebih baik bagi saya. Hanya apa yang saya pelajari dan tempati. Pemrogram sering membuat perang suci karena pilihan pribadi. Manusia lain juga melakukannya.

Saya adalah pengguna lincah yang mencoba untuk tetap berpikiran terbuka tentang Git, dan saya dengan bebas mengakui bahwa itu tidak "menjadi hal favorit saya yang baru" dengan tingkat yang sama seperti yang dimiliki Mercurial. Saya pikir Git benar-benar sangat baik.

Contoh balasan untuk GIT / kompleksitas lincah: Dukungan Nice GIT dibangun ke dalam XCode, di Mac. Kurang mudah menggunakan XCode dengan Mercurial dari GIT.

Pengalaman saya dengan GIT sejauh ini adalah saya menjadi bingung dan tersesat dan perlu lebih banyak membaca dokumentasi saat menggunakannya. Saya percaya bahwa banyak dokumentasi telah ditulis, tetapi tidak ada yang memungkinkan saya untuk "grok" itu. Kedua, saya dapat memodifikasi dan memperluas Mercurial dengan mudah di Python, dan seperti saya mahir dalam Python, dan siapa pun yang benar-benar bisa belajar python dengan cepat, sepertinya ini merupakan keuntungan bagi saya. Saya juga tahu C, dan menulis ekstensi Python di C, jadi saya kira suatu hari, jika saya membutuhkannya, saya bisa dengan mudah menulis ekstensi Git di C.

Kemudahan penggunaan bukanlah sesuatu yang mudah untuk diukur. Itu ada di sana, dan saya pikir itu tidak sepenuhnya subjektif, tetapi kami tidak memiliki teknik pengukuran objektif yang baik. Akan seperti apa unit untuk kemudahan penggunaan? Milli-iPod?

Saya tidak begitu partisan untuk menjadi 100% pro-mercurial, dan 100% anti-git. Saya lebih nyaman menggunakan Mercurial sekarang, di Windows dan di Linux, dan ketika saya mulai melakukan lebih banyak pekerjaan Mac, saya berharap bahwa saya akan mencoba untuk tetap menggunakan XCode + GIT.

Update 2013: Saya telah sekarang digunakan Mercurial DAN GIT cukup lama untuk menemukan beberapa fitur yang saya berharap itu yang Git memiliki, seperti ini pertanyaan tentang strategi gabungan. Benar-benar Git luar biasa, jika sulit dipelajari, dan terkadang rumit.


7

Ada beberapa hal yang IMO kemungkinan akan membuat pengguna baru keluar dari Git:

  1. Budaya Git lebih sentris baris perintah. Walaupun kedua alat cenderung terlalu fokus pada baris perintah (seperti yang telah saya katakan beberapa kali, instruksi baris perintah mungkin lebih kuat dan lebih lancar, tetapi itu bukan strategi pemasaran yang baik ), ini jauh lebih banyak terjadi pada Git. Sedangkan Mercurial memiliki alat GUI standar de facto di TortoiseHg, yang bahkan merupakan opsi unduhan default untuk pengguna Windows di beranda Mercurial, Git memiliki beberapa ujung depan GUI yang bersaing (TortoiseGit, Git Extensions, gitk, dll) yang tidak diiklankan dengan baik di situs web Git, dan yang semuanya sangat merusak pemandangan. (Teks hitam pada label merah? Ayo, TortoiseGit, Anda bisa melakukan lebih baik dari itu!) Ada juga sikap yang jauh lebih luas di komunitas Git bahwa orang yang menggunakan alat GUI bukanlah pengembang perangkat lunak yang tepat.

  2. Git memiliki beberapa standar out-of-the-box yang masuk akal bagi pengguna tingkat lanjut, tetapi cenderung mengejutkan jika tidak mengintimidasi pengguna baru. Sebagai contoh, itu jauh lebih agresif tentang mengotomatisasi tugas-tugas seperti penggabungan (misalnya, git pull secara otomatis menggabungkan dan melakukan jika memungkinkan). Ada kasus untuk penggabungan sepenuhnya otomatis , tetapi sebagian besar pengguna yang tidak berpengalaman takut penggabungan, dan perlu diberi kesempatan untuk mendapatkan kepercayaan pada alat mereka sebelum melepaskan kekuatan penuh mereka pada kode sumber mereka.

  3. Dokumentasi dan kompleksitas yang melekat:

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

3
Sebenarnya, saya lebih suka bantuan yang panjangnya 912 baris daripada bantuan yang 64.
Dysaster

10
Sebenarnya, saya lebih suka UI yang sangat intuitif dan mulus sehingga Anda tidak perlu bantuan di tempat pertama.
jammycakes

2
Saya ingin GUI dan bantuannya. :) Yang nampaknya intuitif bagi saya adalah kekacauan bagi orang lain.
Disaster

1
Tentu, tetapi ketika bantuan diperlukan, itu harus mudah diikuti.
jammycakes

3
Saya telah memikirkan analogi baru; Git seperti C ++ (maaf Linus!) Dan Mercurial seperti Pascal. Apa yang tersirat dan hanya dapat dilakukan satu cara dalam Pascal (atau Mercurial) dapat dilakukan secara eksplisit, sembilan belas cara berbeda dalam C ++ (dan Git). Beberapa orang lebih suka powertools dengan lebih banyak tombol dan tuas, dan Git adalah itu.
Warren P

3

Satu hal yang bisa saya pikirkan adalah

git add .
git commit -am "message"

vs.

hg ci -Am "message"

git commit -atidak menambahkan file yang baru dibuat, hg ci -Atidak, yang berarti bahwa sesuatu yang membutuhkan dua perintah dengan git dapat dilakukan dengan satu perintah di Mercurial. Kemudian lagi, "kurang mengetik" tidak berarti "lebih ramah pengguna".


11
Saya sering menemukan bahwa dalam alur kerja saya, secara otomatis menambahkan file baru sebenarnya tidak diinginkan. Saya datang untuk lebih suka cara git commit -akerjanya hanya karena membuatnya lebih mudah untuk mengontrol apa yang dilakukan dan tidak ditambahkan untuk komit yang diberikan. (Sebenarnya bukan tidak biasa bagi saya untuk menentukan nama path individual untuk setiap orang svn ciagar tidak menambahkan materi yang tidak terkait ke komit.)
greyfade

3
Cukup adil, tapi saya percaya bahwa hg citanpa -Abendera itu setara dengan git commit -a. Saya telah menggunakan git jauh lebih banyak daripada hg, jadi saya tidak 100% yakin.
Zhehao Mao

Saya sudah memeriksa, hg ci== git commit -a.
Zhehao Mao

tetapi jika Anda menentukan file tertentu dengan komit hg, Anda dapat menghindari menarik yang tidak Anda inginkan. Dalam kasus yang jarang terjadi di mana saya ingin kontrol ini, saya menemukan ini berfungsi dengan baik.
Alex Miller

1
mengapa Anda "git add." dan kemudian "git commit -am"? Bukankah semuanya sudah ditambahkan ke indeks?
jacobangel

3

Karena.

Git memaparkan jauh lebih banyak dari nyali daripada mercurial. Anda dapat dengan senang hati menggunakan lincah dalam beberapa menit setelah mengambilnya, tetapi saya menemukan git masih sangat sulit untuk diatasi setelah beberapa bulan bergulat dengannya (saya telah melakukan sangat sedikit selama beberapa bulan terakhir selain mencoba belajar git ). Saya menggunakan keduanya dari baris perintah dan sebagian besar di Linux jadi ini bukan hanya keengganan untuk antarmuka baris perintah.

Salah satu contoh sederhana adalah flag dan argumen command line yang relatif sedikit diperlukan untuk mercurial dibandingkan dengan git. Area staging dan perilaku perintah add di git juga menambahkan lebih banyak kompleksitas daripada yang diperlukan. Trio reset, checkout, dan revert serta berbagai permutasi mereka menambah kompleksitas yang sangat besar, yang sebenarnya tidak perlu ketika Anda menyaksikan sifat sederhana dari revert dan pembaruan pada mercurial.

Saya setuju dengan komentar di atas juga tentang Hginit , itu pasti membuat lincah jauh lebih mudah untuk dipahami. Ditulis dengan baik dan sangat mudah dimengerti. Tidak ada dokumentasi yang ditulis untuk git yang mendekati. Pertama-tama, temukan sebagian besar dari apa yang ditulis oleh Scott Chacone (yang telah menulis sebagian besar dokumentasi / buku tentang git) secara membingungkan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.