ทำไม Mercurial ถึงคิดว่าง่ายกว่า Git

เมื่อดูที่การเปรียบเทียบดูเหมือนว่าฉันอาจมีการแมป 1: 1 ระหว่างชุดคุณลักษณะของพวกเขา แต่ข้อความที่อ้างถึงบ่อยครั้งก็คือ "Mercurial is easy" พื้นฐานของข้อความนี้คืออะไร? (ถ้ามี)

ตรงประเด็น: ให้บอกว่าคุณต้องการเปลี่ยนชื่อผู้ใช้ในการกระทำก่อนหน้านี้ทั้งหมดของคุณ ฉันต้องทำหลายครั้งด้วยเหตุผลหลายประการ

เวอร์ชัน 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:

ไฟล์hors.convert.list:

<oldname>=<newname>

บรรทัดคำสั่ง:

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

ตอนนี้อันไหนที่ดูใช้ง่ายกว่ากัน?

หมายเหตุ: ฉันใช้เวลา 2 ปีในการทำงานกับ Git เพียงลำพังดังนั้นนี่ไม่ใช่ "ฉันเกลียดมันฉันไม่ได้รับมันใน 2 วินาที"

สำหรับฉันมันคือการใช้งาน Git นั้นเน้นลินุกซ์เป็นอย่างมากในการทำสิ่งต่างๆ นั่นหมายถึงบรรทัดคำสั่งหน้าคนและค้นหาด้วยตัวคุณเอง มันมี GUI ที่แย่มาก ๆ (หมายเหตุ: ฉันกำลังอ้างอิง msysGit นี้เมื่อประมาณหนึ่งปีที่แล้ว) ซึ่งดูเหมือนว่าจะเข้าทางของฉัน ฉันแทบจะไม่สามารถใช้มัน

บรรทัดคำสั่งแย่ลง การเป็นโปรแกรม Linux บน Windows มันยากมากที่จะใช้ แทนที่จะเป็นพอร์ตดั้งเดิมพวกเขาเพียงห่อคอมไพล์ด้วย MinGW (คิดว่า cygwin) ซึ่งทำให้การทำงานกับมันยากขึ้นมาก MinGW ไม่ใช่ Windows Command Prompt และทำหน้าที่ต่างกัน มันบ้าว่านี่เป็นวิธีเดียวที่จะทำงานกับ Git แม้แต่ใน Linux ก็ดูเหมือนจะเป็นวิธีเดียวที่จะทำงานกับบรรทัดคำสั่งตรง โครงการเช่น RabbitVCS ช่วยบ้าง แต่ก็ไม่ได้ทรงพลังมาก

แนวทางของบรรทัดคำสั่งและการเป็นโปรแกรม linux หมายความว่าคู่มือ howto เกือบทั้งหมดเอกสารวิธีใช้และคำถามในฟอรัม / คำถามเกี่ยวกับ QA อาศัยการใช้คำสั่งมหึมาดังกล่าว คำสั่ง SCM พื้นฐาน (กระทำ, ดึง, ดัน) นั้นไม่ซับซ้อน แต่มีความซับซ้อนเพิ่มมากขึ้นเรื่อย ๆ

ฉันยังเกลียดสถานที่แห่งเดียวที่ผู้ใช้คอมไพล์ OSS ดูเหมือนจะค้างคาอยู่: Github เมื่อคุณไปที่หน้า GitHub ครั้งแรกมันจะตบหน้าคุณด้วยทุกสิ่งที่คุณสามารถทำได้ สำหรับฉันหน้าคอมไพล์โปรเจ็กต์นั้นดูวุ่นวายวุ่นวายและมีพลังมากเกินไป แม้แต่คำอธิบายว่าโครงการคืออะไรถูกผลักลงไปด้านล่าง Github สร้างความเจ็บปวดให้กับผู้ที่ไม่มีเว็บไซต์เต็มรูปแบบอยู่แล้ว ติดตามปัญหาของมันก็แย่มากและสับสน คุณสมบัติเกินพิกัด

ผู้ใช้ Git ก็ดูเหมือนจะนับถืออย่างมาก ผู้ใช้ Git ดูเหมือนจะเป็นผู้ที่เริ่มต้น "สงครามศักดิ์สิทธิ์" ซึ่ง DVCS ดีกว่าอยู่แล้วซึ่งบังคับให้ผู้ใช้ Mercurial ปกป้องตนเอง ไซต์เช่นhttp://whygitisbetterthanx.com/แสดงความเย่อหยิ่งและความคิด "ใช้ซอฟต์แวร์ของฉันหรือตาย" เกือบ หลายครั้งที่ฉันเข้าไปในสถานที่ช่วยเหลือต่าง ๆ เพียงเพื่อจะได้รู้ตัวว่าไม่รู้ X ใช้ X ไว้ล่วงหน้าใช้ Windows ฯลฯ มันบ้า

Mercurial ในทางกลับกันดูเหมือนว่าจะไปสู่แนวทางที่อ่อนโยนกว่า ของตัวเองที่หน้าบ้านดูเหมือนมากขึ้นเป็นมิตรกับผู้ใช้ใหม่กว่าGit ของ ในการค้นหาของ Google แบบง่ายผลลัพธ์ที่ 5 คือ TortoiseHg ซึ่งเป็น GUI ที่ดีมากสำหรับ Mercurial วิธีการทั้งหมดของพวกเขาดูเหมือนจะเรียบง่ายก่อนใช้พลังงานในภายหลัง

ด้วย Mercurial ฉันไม่มี SSH ไร้สาระ (SSH เป็นนรกบน Windows) ฉันไม่มีคำสั่งที่ซับซ้อนอย่างโง่เขลาฉันไม่มีผู้ใช้ที่ติดตามลัทธิฉันไม่มีความบ้าคลั่ง Mercurial ใช้งานได้แล้ว

TortoiseHg ให้ส่วนต่อประสานที่ใช้งานได้จริง (แม้ว่าเมื่อเร็ว ๆ นี้ดูเหมือนว่าจะเพิ่มขึ้น) ซึ่งมีคุณสมบัติที่มีประโยชน์จริง ๆ ตัวเลือกจะถูก จำกัด ในสิ่งที่คุณต้องการลบความยุ่งเหยิงและตัวเลือกที่ไม่ค่อยได้ใช้ นอกจากนี้ยังมีค่าเริ่มต้นที่เหมาะสมอีกมากมาย

Mercurial เป็นมิตรกับผู้มาใหม่มากง่ายต่อการรับ แม้แต่หัวข้อที่ซับซ้อนมากขึ้นเช่นรูปแบบการแตกแขนงที่แตกต่างกันและการแก้ไขประวัติก็ง่ายต่อการติดตาม ฉันหยิบ Mercurial ขึ้นมาอย่างรวดเร็วและไม่ลำบาก

Mercurial ยังใช้งานได้เป็นครั้งแรกด้วยการตั้งค่าเล็กน้อย บนระบบปฏิบัติการใด ๆ ฉันสามารถติดตั้ง TortoiseHg และรับคุณสมบัติทั้งหมดที่ฉันต้องการ (คำสั่งเมนูบริบทส่วนใหญ่) โดยไม่ต้องค้นหา Guis ที่แตกต่างกัน ที่ขาดหายไปก็คือการตั้งค่า SSH (ครึ่งหนึ่งของคำแนะนำที่นั่นบอกว่าจะใช้ Putty, Plink และ Pagent ในขณะที่อีกครึ่งหนึ่งบอกว่าจะใช้ ssh-keygen) สำหรับผู้ใช้ใหม่ TortoiseHg ใช้เวลาในการตั้งค่าในขณะที่ Git ใช้เวลา 30 นาทีถึงหนึ่งชั่วโมงด้วย googling มากมาย

สุดท้ายคุณมี repos ออนไลน์ เทียบเท่า Github คือ BitBucket ซึ่งมีปัญหาบางอย่างที่ฉันระบุไว้ข้างต้น อย่างไรก็ตามยังมี Google Code เมื่อฉันไปที่โครงการ Google Codeฉันไม่ได้รับฟีเจอร์โอเวอร์โหลดฉันได้รับส่วนต่อประสานที่ดี Google Code เป็นคำสั่งผสมแบบ repo / เว็บไซต์ออนไลน์ซึ่งช่วยให้โครงการ OSS ที่ไม่มีการตั้งค่าไซต์มีอยู่จริง ๆ ฉันรู้สึกสบายใจที่จะใช้ Google Code เป็นเว็บไซต์โครงการของฉันสักพักสร้างเว็บไซต์เมื่อจำเป็นเท่านั้น ตัวติดตามปัญหาของมันยังทรงพลังเหมาะอย่างยิ่งในการติดตามปัญหาที่ไร้ประโยชน์เกือบระหว่าง Github กับBugzilla ที่น่าประหลาดใจ

Mercurial ใช้งานได้ครั้งแรกทุกครั้ง Git เข้ามาในทางของฉันและทำให้ฉันโกรธยิ่งฉันใช้มากขึ้นเท่านั้น

Git กับ Mercurial

โดยทั่วไปแล้ว Mercurial นั้นเชื่อว่าจะง่ายกว่าและเรียนรู้ได้ง่ายกว่า Git ในทางกลับกันมักจะมีการรับรู้ว่า Git นั้นมีความยืดหยุ่นและมีประสิทธิภาพมากกว่า นี่เป็นเพราะส่วนหนึ่งเนื่องจาก Git มีแนวโน้มที่จะให้คำสั่งระดับต่ำมากขึ้น แต่ส่วนหนึ่งเป็นเพราะ Mercurial เริ่มต้นมีแนวโน้มที่จะซ่อนคุณสมบัติขั้นสูงปล่อยให้ผู้ใช้แก้ไขไฟล์ Mercurial เพื่อเปิดใช้งานคุณสมบัติขั้นสูงที่พวกเขาต้องการ สิ่งนี้มักจะนำไปสู่การรับรู้ว่าคุณสมบัติขั้นสูงไม่สามารถใช้ได้ใน Mercurial

แนวคิด Git

Mercurial ให้ความสำคัญกับส่วนต่อประสานมากขึ้นซึ่งทำให้ง่ายต่อการเรียนรู้ เมื่อเปรียบเทียบกับ Git จำเป็นต้องมีความเข้าใจที่ตื้นกว่าเพื่อใช้งานกับ Mercurial ในลักษณะที่มีประโยชน์ ในระยะยาวการห่อหุ้มดังกล่าวทำให้ Mercurial มีลักษณะที่ผิด ๆ ว่ามีพลังน้อยลงและมีคุณสมบัติมากกว่าที่เป็นจริง

บริบท: ฉันใช้ทั้ง Mercurial (สำหรับงาน) และ Git (สำหรับโครงการด้านข้างและโอเพ่นซอร์ส) เป็นประจำทุกวัน ฉันใช้เครื่องมือข้อความเป็นหลักทั้ง (ไม่ใช่ IDE) และฉันใช้ Mac

โดยทั่วไปแล้วฉันพบว่า Mercurial ทำงานง่ายขึ้น บางสิ่งที่ฉันพบทำให้ Mercurial ง่ายขึ้น:

1. ขาดดัชนี ดัชนีเป็นเครื่องมือที่ทรงพลังที่ทำให้ฟีเจอร์ของ Git มากมาย แต่มันก็เป็นเลเยอร์พิเศษที่เพิ่มขั้นตอนในหลาย ๆ สิ่งที่ฉันทำอย่างสม่ำเสมอ เวิร์กโฟลว์ของ Mercurial คล้ายกับบางอย่างใน svn
2. หมายเลขการตรวจทานแทน shas นี่เป็นสิ่งเล็ก ๆ ที่ฉันพบว่าทำให้การทำงานกับทุก ๆ วันนั้นง่ายขึ้นมากใน Mercurial เป็นวิธีที่ง่ายกว่าที่จะผลักดันตัวเลขการแก้ไขสองสามครั้งเข้าไปในหัวของคุณระหว่างการรีบูตการผสานและอื่น ๆ ในขณะที่เขียนคำสั่งแทนที่จะทำแบบเดียวกันกับ shas ที่สั้นกว่า
3. สาขา วิธีการของ Git ในการแยกสาขาโดยการตั้งชื่อการกระทำนั้นมีประสิทธิภาพและแตกต่างอย่างมากจากระบบควบคุมเวอร์ชันอื่น ๆ มันทำให้บางสิ่งง่ายขึ้นมาก ฉันพบว่าวิธีการของ Mercurial จับคู่ svn คิดดีขึ้นเล็กน้อยและทำให้ง่ายขึ้นในการเข้าใจประวัติศาสตร์สาขา นี่อาจเป็นสิ่งที่ชอบ

นี่เป็นเรื่องส่วนตัวมากและขึ้นอยู่กับคนคนหนึ่ง แต่ใช่ฉันจะไปกับคนที่ใหม่กับ VCS หรือคนที่มาจาก VCS "โรงเรียนเก่า" Mercurial จะดูง่ายขึ้น

ตัวอย่างเช่นการเพิ่มไฟล์การไม่มีอยู่ของดัชนีใน Hg ความง่ายในการย้อนกลับไปยังการแก้ไขเก่าและการแตกแขนงจากที่นั่น (เพียงแค่อัปเดตและกระทำ) เป็นตัวอย่างที่ชัดเจนที่สุด ตอนนี้คุณลักษณะส่วนใหญ่ของระบบหนึ่งสามารถเลียนแบบได้ในอีกระบบหนึ่งและในทางกลับกัน แต่นั่นต้องใช้ความรู้บางอย่างใน Git ในขณะที่ Mercurial เป็นค่าเริ่มต้น สิ่งเล็ก ๆ น้อย ๆ เหล่านั้น - สวิตช์ที่นี่และที่นั่นพฤติกรรมที่ไม่ชัดเจนในคำสั่งเดียวและอื่น ๆ ... สิ่งเหล่านี้รวมกันและในท้ายที่สุดระบบหนึ่งดูเหมือนจะใช้งานง่ายกว่าอีกระบบหนึ่ง

เพียงเพื่อให้คำตอบสมบูรณ์ ฉันใช้คอมไพล์ แต่เมื่อแนะนำ VCS ให้กับคนที่ "ใหม่กับพวกเขา" ฉันมักจะแนะนำ Mercurial ฉันจำได้ว่าเมื่อมันเข้ามาในมือของฉันครั้งแรกมันให้ความรู้สึกเป็นธรรมชาติมาก เป็นประสบการณ์ของฉันที่ Mercurial ผลิต wtf / นาทีน้อยกว่า Git

ฉันคิดว่ามันง่ายอย่างนี้ Mercurial มีรูปแบบที่คุ้นเคยมากกว่า (โดยเฉพาะสำหรับผู้ใช้ SVN) และมีเอกสารที่ค่อนข้างดี เมื่อคุณคุ้นเคยกับไวยากรณ์ Git แล้วคุณจะพบว่ามันใช้งานง่ายเหมือนอย่างอื่น

การรับรู้อาจเปลี่ยนแปลงไปตามกาลเวลา Mercurial ได้รับการออกแบบมาเป็นอย่างดี Git Mercurial ดูเหมือนจะง่ายต่อการเรียนรู้ (อย่างน้อยก็สำหรับฉัน) และมีปัญหาที่ฉันพบใน Git ว่าฉันไม่ได้มีคู่ขนานกันใน Mercurial ฉันพยายามเรียนรู้ Python และ Ruby และไกลขึ้นเร็วขึ้นด้วย Python นั่นไม่ได้หมายความว่า Python จะดีกว่า Ruby ทุกครั้งหรือแม้แต่ดีกว่าสำหรับฉัน มันเป็นสิ่งที่ฉันเรียนรู้และติดอยู่ โปรแกรมเมอร์มักทำให้สงครามศักดิ์สิทธิ์ไม่เป็นที่ต้องการ มนุษย์คนอื่นก็ทำเช่นกัน

ฉันเป็นผู้ใช้ Mercurial ที่พยายามรักษาใจที่เปิดกว้างเกี่ยวกับ Git และฉันยอมรับอย่างอิสระว่าจะไม่ "กลายเป็นสิ่งที่ฉันโปรดปรานใหม่" ในระดับเดียวกับ Mercurial ฉันคิดว่า Git นั้นดีจริงๆ

ตัวอย่างตัวนับสำหรับความซับซ้อนของ GIT / Mercurial: การสนับสนุน GIT ที่ดีถูกสร้างขึ้นใน XCode บน Mac ใช้งานง่าย XCode น้อยกว่า Mercurial กว่า GIT

ประสบการณ์ของฉันกับ GIT จนถึงขณะนี้คือฉันสับสนและหลงทางและต้องไปอ่านเอกสารเพิ่มเติมในขณะที่ใช้งาน ฉันเชื่อว่าเอกสารจำนวนมากถูกเขียนขึ้น แต่ไม่มีอะไรที่ทำให้ฉัน "คร่ำครวญ" ได้ ประการที่สองฉันสามารถปรับเปลี่ยนและขยาย Mercurial ได้อย่างง่ายดายใน Python และเมื่อฉันเชี่ยวชาญใน Python และในขณะที่ทุกคนสามารถเรียนรู้ Python ได้อย่างรวดเร็วดูเหมือนว่าจะเป็นประโยชน์สำหรับฉัน ฉันรู้จัก C และเขียนส่วนขยาย Python ใน C ดังนั้นฉันคิดว่าสักวันถ้าฉันต้องการมันฉันก็สามารถเขียน Git extension ใน C ได้อย่างง่ายดาย

ความง่ายในการใช้งานไม่ใช่สิ่งที่ง่ายต่อการหาจำนวน มันอยู่ที่นั่นและฉันไม่คิดว่ามันเป็นอัตวิสัยทั้งหมด แต่เราไม่มีเทคนิคการวัดที่ดี ยูนิตที่ใช้งานง่ายจะเป็นอย่างไร หนึ่งในพัน iPods?

ฉันไม่เข้าข้างเลยว่าเป็นคนโปร 100% และต่อต้าน 100% ฉันรู้สึกสะดวกสบายมากขึ้นกับ Mercurial ในตอนนี้บน Windows และบน Linux และเมื่อฉันเริ่มทำงาน Mac มากขึ้นฉันคาดหวังว่าฉันจะพยายามติดกับ XCode + GIT

ปรับปรุง 2013:ฉันได้ใช้ตอนนี้ Mercurial และ GIT นานพอที่จะพบคุณสมบัติบางอย่างที่ฉันต้องการมันมีที่ Git มีเช่นนี้คำถามเกี่ยวกับกลยุทธ์การผสาน จริง ๆ แล้ว Git นั้นน่าทึ่งถ้าเรียนรู้ยากและบางครั้งก็ซับซ้อนอย่างน่าเกรงขาม

มีบางสิ่งที่ IMO มีแนวโน้มที่จะนำผู้ใช้ใหม่ออกจาก Git:

1. วัฒนธรรม Git นั้นเป็นศูนย์กลางของบรรทัดคำสั่งมากกว่า ในขณะที่เครื่องมือทั้งสองมักจะเน้นที่บรรทัดคำสั่งมากเกินไป (อย่างที่ฉันพูดไปหลายครั้งคำสั่งของบรรทัดคำสั่งอาจมีประสิทธิภาพและคล่องแคล่วมากขึ้น แต่มันไม่ใช่กลยุทธ์การตลาดที่ดี ) นี่เป็นกรณีของ Git ในขณะที่ Mercurial มีเครื่องมือ GUI มาตรฐานแบบพฤตินัยใน TortoiseHg ซึ่งเป็นตัวเลือกการดาวน์โหลดเริ่มต้นสำหรับผู้ใช้ Windows บนหน้าแรกของ Mercurial Git มีส่วนหน้า GUI ที่แข่งขันกันหลายส่วน (TortoiseGit, Git Extensions, gitk และอื่น ๆ ) บนเว็บไซต์ Git และทั้งหมดนี้เป็นสิ่งที่อุจาดนัยน์ตาสมบูรณ์ (ตัวอักษรสีดำบนฉลากสีแดง? C'mon, TortoiseGit คุณสามารถทำได้ดีกว่านั้น!) นอกจากนี้ยังมีทัศนคติที่แพร่หลายมากขึ้นในชุมชน Git ที่ผู้ใช้เครื่องมือ GUI ไม่ได้เป็นนักพัฒนาซอฟต์แวร์ที่เหมาะสม

2. Git มีค่าเริ่มต้นที่ไม่เป็นไปตามข้อกำหนดหลายประการซึ่งเหมาะสมกับผู้ใช้ขั้นสูง แต่น่าจะแปลกใจหากไม่ได้ข่มขู่ผู้ใช้รายใหม่ ยกตัวอย่างเช่นมันมีความก้าวร้าวมากขึ้นเกี่ยวกับการทำงานอัตโนมัติเช่นการรวม (ตัวอย่างเช่น git pull จะทำการผสานและกระทำโดยอัตโนมัติหากเป็นไปได้) มีกรณีสำหรับการผสานอัตโนมัติแต่ผู้ใช้ที่ไม่มีประสบการณ์ส่วนใหญ่กลัวการรวมและต้องได้รับโอกาสที่จะได้รับความมั่นใจในเครื่องมือของพวกเขาก่อนที่จะปลดปล่อยพลังเต็มในซอร์สโค้ดของพวกเขา

3. เอกสารและความซับซ้อนโดยธรรมชาติ:

   $ 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 สามารถทำได้ด้วยคำสั่งเดียวใน Mercurial จากนั้นอีกครั้ง "พิมพ์น้อยลง" ไม่ได้แปลว่า "เป็นมิตรกับผู้ใช้มากขึ้น"

เพราะมันเป็น.

Git เผยให้เห็นถึงความกล้ามากกว่า Mercurial คุณสามารถใช้ mercurial ได้อย่างมีความสุขภายในไม่กี่นาทีหลังจากหยิบมันขึ้นมา แต่ฉันพบว่าคอมพิวติงยังคงยากที่จะต่อสู้กับหลังจากผ่านไปสองสามเดือนของการต่อสู้ด้วย (ฉันได้ทำน้อยมากในช่วงสองสามเดือนที่ผ่านมา ) ฉันใช้ทั้งจากบรรทัดคำสั่งและส่วนใหญ่บน Linux ดังนั้นนี่ไม่ใช่เพียงแค่ความเกลียดชังต่ออินเตอร์เฟสบรรทัดคำสั่ง

ตัวอย่างง่ายๆอย่างหนึ่งคือค่าสถานะที่ค่อนข้างน้อยและอาร์กิวเมนต์บรรทัดคำสั่งที่จำเป็นสำหรับ mercurial เมื่อเปรียบเทียบกับ git พื้นที่การจัดเตรียมและพฤติกรรมของคำสั่งเพิ่มในคอมไพล์ยังเพิ่มความซับซ้อนมากกว่าที่จำเป็น การรีเซ็ต, การชำระเงินและการย้อนกลับและการเรียงสับเปลี่ยนหลายครั้งของพวกเขาเพิ่มความซับซ้อนอย่างมากซึ่งไม่จำเป็นเลยเมื่อคุณเห็นธรรมชาติของการย้อนกลับและอัปเดตเกี่ยวกับ Mercurial

ฉันเห็นด้วยกับความคิดเห็นข้างต้นเกี่ยวกับHginitมันทำให้ Mercurial เข้าใจได้ง่ายขึ้นมาก เขียนได้ดีและเข้าใจง่ายมาก ไม่มีเอกสารใดที่เขียนขึ้นสำหรับ git เข้ามาใกล้ สำหรับฉันค้นหาสิ่งที่เขียนโดย Scott Chacone (ผู้เขียนเอกสาร / หนังสือเกี่ยวกับคอมไพล์ส่วนใหญ่) อย่างสับสนโดยเฉพาะอย่างยิ่ง