เหตุผลที่ SQLite ไม่ใช้ Git

 (sqlite.org)
2 คะแนน โดย GN⁺ 2023-07-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ซอร์สโค้ดของ SQLite ถูกจัดการด้วย Fossil ไม่ใช่ Git และ Fossil คือระบบควบคุมเวอร์ชันที่ถูกออกแบบและเขียนขึ้นมาโดยเฉพาะเพื่อรองรับ SQLite
  • Fossil มีความสามารถด้าน การรับรู้ภาพรวมของสถานะ (situational awareness) ที่แสดงการเปลี่ยนแปลงล่าสุดของทุกสาขาบนหน้าจอเดียว และเข้าถึงได้แม้จากโทรศัพท์มือถือ
  • Git ติดตามได้เฉพาะประวัติก่อนหน้า ของเช็กอิน ขณะที่การติดตามรายการสืบทอดถัดไป (descendents) ทำได้ยาก แต่ Fossil แสดงเช็กอินถัดไปและโครงสร้างการแตกสาขาได้ง่าย
  • Git ทำให้ต้องคำนึงถึง 5 สถานะ ได้แก่ working directory, staging, local/remote head เป็นต้น ขณะที่ Fossil พิจารณาแค่ working directory และเช็กอิน จึงมี ภาระน้อยลง 60%
  • แม้ผู้ใช้ที่คุ้นเคยกับ Git ก็ยัง เข้าถึงซอร์สของ SQLite ได้ในแบบเดิม ผ่าน GitHub mirror, การดาวน์โหลดผ่านเว็บ, หรือการติดตั้ง Fossil

ภาพรวมและสมมติฐานของบทความ

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

เหตุผลที่ SQLite ไม่ใช้ Git

Git ให้การรับรู้ภาพรวมของสถานะได้ไม่ดี

  • timeline ของ Fossil แสดงสรุปการเปลี่ยนแปลงล่าสุดของทุกสาขาบนหน้าจอเดียว สามารถคลิกดูรายละเอียดได้ภายในไม่กี่ครั้ง และใช้งานได้แม้บนโทรศัพท์มือถือ
  • GitHub และ GitLab ไม่มีฟีเจอร์ที่เทียบได้โดยตรง
    • มุมมอง network เรนเดอร์ช้า (ก่อนแคช) รายละเอียดน้อย และแทบใช้งานบนมือถือไม่ได้
    • มุมมอง commits นั้นเร็วและใช้บนมือถือได้ แต่ แสดงได้ทีละสาขาเดียว จึงยากที่จะรู้ว่าดูการเปลี่ยนแปลงครบทั้งหมดหรือยัง
    • GitHub และ GitLab เป็น บริการของบุคคลที่สาม ไม่ใช่องค์ประกอบหลักของ Git จึงเพิ่มการพึ่งพาเพิ่มเติม
  • ผู้ใช้ Git มักติดตั้งตัวดูกราฟิกจากภายนอก แต่ก็ต้องติดตั้งและดูแลแยกต่างหาก และมักผูกกับแพลตฟอร์มใดแพลตฟอร์มหนึ่ง
    • หนึ่งในเครื่องมือที่ดีอย่าง GitUp ใช้งานได้เฉพาะบน Mac
    • ทุกเครื่องมือจำเป็นต้องซิงก์รีโพซิทอรีแบบโลคัลก่อนแล้วจึงเปิดเดสก์ท็อป GUI ทำให้ไม่สามารถตรวจสอบสถานะโปรเจกต์จากภายนอกผ่านโทรศัพท์มือถือได้

Git ทำให้หาสิ่งที่สืบทอดต่อจากเช็กอินได้ยาก

  • Git มองย้อนกลับไปยังอดีตได้ แต่ติดตามสิ่งที่เกิดขึ้นต่อจากนั้นได้ยาก
    • สำหรับเช็กอินเก่าอันหนึ่ง สามารถเห็นประวัติก่อนหน้าได้ แต่ดูได้ยากว่าอะไรตามมาทีหลัง
  • Fossil มีหน้าจอที่แสดงเช็กอินทั้งหมดที่แตกแขนงมาจากเมเจอร์รีลีสล่าสุด
  • ใน Git การหาลูกหลานไม่ถึงกับเป็นไปไม่ได้ แต่ทำได้ยาก
    • มีลำดับคำสั่งสำหรับ unix อยู่ใน stackoverflow แต่คำสั่งนั้นจะแสดง แค่รายชื่อรายการสืบทอดโดยไม่มีโครงสร้างสาขา
    • คำสั่งดังกล่าวทำงานได้ก็ต่อเมื่อมี local clone และไม่สามารถดูรายการสืบทอดผ่านเว็บอินเทอร์เฟซอย่าง GitHub หรือ GitLab ได้
  • Fossil แสดงข้อมูลรายการสืบทอดไว้ทั่วทั้งหน้าเว็บ
    • ในหน้าข้อมูลเช็กอินทุกหน้า จะมีกราฟ "Context" ขนาดเล็กที่แสดงเช็กอินก่อนหน้าและถัดไป
    • มีฟีเจอร์ช่วยรับรู้ภาพรวม เช่น คลิกไปยังเช็กอินถัดไปได้โดยตรง
  • ในทางทฤษฎี Git ก็พอทำได้ด้วยส่วนขยาย เครื่องมือ หรือคำสั่งที่เหมาะสม แต่ไม่ง่ายจึงแทบไม่มีใครทำ ผลคือการรับรู้การเปลี่ยนแปลงของโค้ดโดยนักพัฒนาลดลง

mental model ของ Git ซับซ้อนเกินความจำเป็น

  • ผู้ใช้ Git ต้องคำนึงถึง 5 สิ่งต่อไปนี้อยู่เสมอ
    1. working directory
    2. "index" หรือ staging area
    3. local head
    4. สำเนา local ของ remote head
    5. remote head ตัวจริง
  • ผู้ใช้ Fossil ต้องพิจารณาเพียง working directory และเช็กอินที่กำลังทำงานอยู่ เท่านั้น ซึ่งหมายถึง การกระจายความสนใจน้อยลง 60%
    • ช่วยประหยัดสมาธิที่มีจำกัดของนักพัฒนา (brain-cycles) เพื่อให้โฟกัสกับซอฟต์แวร์ที่กำลังพัฒนาอยู่ได้มากขึ้น
  • ผู้ใช้คนหนึ่งที่ใช้ทั้ง Git และ Fossil กล่าวบน HN ว่า "Fossil ให้ความมั่นใจได้ด้วยคำสั่งเดียวว่าทุกอย่างถูกซิงก์ขึ้นเซิร์ฟเวอร์แล้ว แต่ใน git ผมไม่เคยได้ความมั่นใจแบบนั้น"

Git ไม่ติดตามชื่อสาขาในอดีต

  • Git เก็บ DAG ทั้งหมดของลำดับเช็กอินไว้ก็จริง แต่ แท็กสาขาเป็นข้อมูลโลคัล ที่ไม่ถูกซิงก์ และเมื่อปิดสาขาแล้วก็ไม่ถูกเก็บไว้ จึงทำให้การย้อนดูสาขาเก่าเป็นเรื่องยุ่งยาก
  • ตัวอย่าง: หากถามถึงชะตากรรมของสาขา 'prefer-coroutine-sort-subquery' เมื่อ 2 ปีก่อน
    • Fossil: แสดงอย่างชัดเจนว่าสุดท้ายสาขานั้นถูก merge เข้า trunk จุดเริ่มต้นอยู่ตรงไหน และมีเหตุการณ์ที่การเปลี่ยนแปลงจาก trunk ถูก merge กลับเข้าไปในสาขา 2 ครั้ง
    • GitHub: ไม่สามารถแสดงข้อมูลเหล่านี้ได้เลย และแทบไม่มีประโยชน์หากต้องการสืบว่าเกิดอะไรขึ้น
  • GUI ของบุคคลที่สามอาจทำได้ดีกว่า แต่ก็ยังติดข้อจำกัดที่ Git ไม่เก็บชื่อสาขาเก่าไว้ตอนซิงก์
    • การที่ต้องพึ่งเครื่องมือจากภายนอกเพื่อให้ได้ข้อมูลที่ต้องการนั้นเอง ก็สะท้อนจุดอ่อนของระบบหลัก

Git ต้องการการดูแลจัดการมากกว่า

  • Git เป็นซอฟต์แวร์ที่ซับซ้อน ต้องใช้ตัวติดตั้งสำหรับการติดตั้งและอัปเกรดบนเวิร์กสเตชัน และการตั้งค่า Git server ก็ไม่ใช่เรื่องง่าย
    • คนส่วนใหญ่มักใช้บริการของบุคคลที่สามอย่าง GitHub หรือ GitLab จึงเกิดการพึ่งพาเพิ่มเติม
  • Fossil เป็น ไบนารีแบบสแตนด์อโลนไฟล์เดียวที่เพียงวางไว้ใน $PATH ก็ใช้งานได้เลย
    • ไบนารีเพียงไฟล์เดียวนี้รวมทั้งความสามารถหลักของ Git และฟีเจอร์แบบ GitHub/GitLab ไว้ครบ
    • สามารถดูแล community server ที่มี wiki, ตัวติดตามบั๊ก, ฟอรัม, การแจกจ่ายแพ็กเกจดาวน์โหลด, การจัดการล็อกอิน ฯลฯ ได้โดยไม่ต้องใช้ซอฟต์แวร์เพิ่ม
    • ใช้เวลาเพียงไม่กี่นาทีในการตั้งค่า community server
    • ทำงานได้ลื่นไหลแม้บน VPS ราคา $5/เดือน หรือ Raspberry Pi ขณะที่ GitLab และระบบคล้ายกันต้องการสเปกสูงกว่า
  • ยิ่งภาระในการดูแลน้อยลง นักพัฒนาก็ยิ่งมีเวลาไปทุ่มกับการพัฒนาซอฟต์แวร์ (SQLite) มากกว่าระบบควบคุมเวอร์ชัน

Git มอบประสบการณ์ผู้ใช้ที่ไม่ดี

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

คู่มือเข้าถึงซอร์สโค้ด SQLite สำหรับผู้ใช้ Git

GitHub mirror อย่างเป็นทางการ

  • ตั้งแต่ 2019-03-20 เป็นต้นมา มี official Git mirror ของซอร์ส SQLite อยู่บน GitHub
  • เป็นการส่งออกแบบเพิ่มทีละส่วนจากรีโพซิทอรี Fossil หลัก โดย cron job จะอัปเดตรีโพซิทอรี GitHub ทุก 1 ชั่วโมง
    • เป็น mirror ทางเดียวแบบอ่านอย่างเดียว ไม่รับ pull request หรือการแก้ไขใด ๆ
    • การเปลี่ยนแปลงทั้งหมดจะรับเข้าผ่าน Fossil เท่านั้น
  • แฮชที่ใช้ระบุเช็กอินและไฟล์จะแตกต่างกันระหว่าง Git mirror กับ Fossil
    • สาเหตุหลักคือ Fossil ใช้แฮช SHA3-256 ส่วน Git ใช้ SHA1
    • ระหว่างการส่งออก จะมีการเพิ่มแฮช Fossil ต้นฉบับไว้ในส่วนท้ายของคอมเมนต์เช็กอิน และเมื่ออ้างอิงเช็กอินของ SQLite แนะนำให้ใช้แฮช Fossil ต้นฉบับเสมอเพื่อป้องกันความสับสน

การเข้าถึงผ่านเว็บ

  • รีโพซิทอรี Fossil ของ SQLite มีลิงก์ดาวน์โหลด Tarball, ZIP Archive และ SQLite Archive สำหรับเวอร์ชันเก่าใด ๆ ก็ได้
  • รูปแบบ URL เรียบง่าย จึงผสานเข้ากับเครื่องมืออัตโนมัติได้ง่าย
    • รูปแบบพื้นฐาน: https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz
    • ใน VERSION สามารถใช้คำนำหน้าแฮช, ชื่อสาขา หรือแท็ก (เช่น "version-3.23.1")
    • ใช้ "release" สำหรับรีลีสล่าสุด และ "trunk" สำหรับ trunk ล่าสุด
    • สำหรับ ZIP และ SQLite Archive ให้เปลี่ยน "/tarball/" เป็น "/zip/" หรือ "/sqlar/"

การเข้าถึงผ่าน Fossil

  • Fossil ติดตั้งและใช้งานได้ง่าย โดยมีขั้นตอนสำหรับ unix ให้ไว้ (Windows ก็คล้ายกัน)
    • ดาวน์โหลดไฟล์ปฏิบัติการ fossil แล้ววางไว้ใน $PATH
    • โคลนรีโพซิทอรีด้วย fossil clone แล้วเปิดด้วย fossil open
    • หลังจากนั้นสามารถรัน ./configure; make ได้ (บน Windows MSVC ใช้ nmake /f Makefile.msc)
  • ใช้คำสั่ง fossil update VERSION เพื่อสลับ checkout ไปยังเวอร์ชันอื่นได้ โดย VERSION ใช้ trunk, คำนำหน้าแฮช, สาขา หรือแท็กได้
  • ภายใน checkout สามารถรัน fossil ui เพื่อเปิดเว็บไซต์แบบโลคัลได้
    • เนื่องจากหากไม่ล็อกอินจะไม่สามารถ push การเปลี่ยนแปลงได้ จึงไม่สามารถทำให้โปรเจกต์เสียหาย และสามารถสำรวจหรือทดลองได้อย่างอิสระ

การตรวจสอบความถูกต้องของซอร์สโค้ด

  • มีไฟล์ "manifest" อยู่ที่รากของ source tree
    • ไฟล์นี้มีชื่อไฟล์ทั้งหมดและแฮช SHA1 หรือ SHA3-256 ของแต่ละไฟล์รวมอยู่ด้วย (ไฟล์เก่าใช้ SHA1 ส่วนไฟล์ใหม่ใช้ SHA3-256)
    • สามารถดึงแฮชออกมาด้วยสคริปต์แล้วตรวจเทียบกับไฟล์ซอร์สเพื่อยืนยันความถูกต้องได้
  • ชื่อแฮชของเช็กอินคือค่าแฮช SHA3-256 ของไฟล์ "manifest" เอง และหากบรรทัดสุดท้ายขึ้นต้นด้วย "# Remove this line..." ก็สามารถละบรรทัดนั้นออกได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-24
ความคิดเห็นจาก Hacker News

  • ผมลองสรุป เครื่องมือควบคุมเวอร์ชัน ที่เคยใช้มาตลอดหลายสิบปี พร้อมปีที่ถูกสร้างและปีสุดท้ายที่ผมใช้: sccs 1973~2000, rcs 1982~2000, cvs 1990~2004, clearcase 1992~2004, perforce 1995~2011, subversion 2000~2015, mercurial 2005~2015, git 2005~ปัจจุบัน
    อย่างน้อยสำหรับผม อายุการใช้งานของเครื่องมือพวกนี้อยู่ราว ๆ 15 ปี
    แต่พอบอกจูเนียร์ว่า “พอพวกคุณอายุเท่าผม git จะกลายเป็นความทรงจำที่ไกลและประหลาด” พวกเขาก็มองผมแปลก ๆ
    git เป็นเครื่องมือที่ยอดเยี่ยมและสมควรประสบความสำเร็จ แต่ถ้าปัญหานี้ จบลงที่ git จริง ๆ ก็คงน่าเสียดาย

    • ถ้ามองอย่างเป็นธรรม เครื่องมือทุกประเภท เมื่อขอบเขตปัญหาถูกทำความเข้าใจดีพอแล้ว ความเร็วของการเปลี่ยนแปลง ก็จะช้าลง
      เคยมีบทความใน Joel on Software ว่าซอฟต์แวร์โดยทั่วไปพอถึงเวอร์ชัน 4 ก็แทบจะสมบูรณ์แล้ว ตัวอย่างที่ยกมาคือซอฟต์แวร์สำนักงาน โดยเฉพาะ Excel
      ถ้าเปิด Excel 4 ตอนนี้ ก็ยังทำฟังก์ชันหลัก ๆ ได้ครบในสาระสำคัญ จึงดูเป็นคำพูดที่มีเหตุผล
      git น่าจะอยู่ได้นานกว่าเครื่องมือควบคุมเวอร์ชันรุ่นก่อน ๆ อย่างน้อยสองเท่า
    • โดยพื้นฐานแล้ว Subversion คือ CVS ที่ทำออกมาให้ถูกต้อง
      ปัญหาคือ CVS เป็นทางตันที่ขยายไปสู่โมเดลการพัฒนาแบบกระจายไม่ได้
      Git กลับไปสู่โมเดล RCS แบบโลคัล แล้วเพิ่ม atomic commit เข้าไป จึงหลุดออกจากจุดเหมาะสมเฉพาะที่อย่าง Subversion ได้
      มีตัวเลือกที่ถกเถียงกันได้ เช่น ไม่ติดตามการเปลี่ยนชื่อ หรือไม่มีเลขรีวิชันแบบเชิงเส้น แต่ก็ไม่ได้กลายเป็นปัญหาใหญ่ และทำให้ทำงานได้อย่างมีประสิทธิภาพมากโดยไม่มีปัญหาด้านประสิทธิภาพแบบ darcs
      เมื่อดูว่าช่วงปี 1995~2010 มีความพยายามมากมายในการแก้ไขระบบควบคุมเวอร์ชัน โมเดลข้อมูลพื้นฐานของ git จึงดูเหมือนจะปรับปรุงได้ยากมาก แม้รวมฟีเจอร์เสริมอย่าง git-lfs แล้วก็ตาม
      command-line interface แบบใหม่อาจเกิดขึ้นได้ แต่การโค่นผู้ครองตลาดเดิมทำได้ยากขึ้นเรื่อย ๆ และรอบตัวผมก็ไม่มีใครใช้ git switch กับ git restore แทน git checkout ที่ถูกยัดหน้าที่เยอะเกินไปและชวนสับสนเลย
    • ไม่รู้ว่าอีก 15 ปีข้างหน้าจะใช้เครื่องมืออะไร แต่สิ่งที่น่าเศร้าจริง ๆ ในรายการนั้นคือเราเลิกใช้ mercurial ไปตั้งแต่ปี 2015 แต่ยังใช้ git อยู่
    • ที่บริษัทแรก ผมย้ายโปรเจกต์จาก clearcase ไปเป็น git แม้แต่ผมที่เกลียด clearcase ก็ยังคิดว่าก่อนหน้านั้นแทบไม่มีเหตุผลจำเป็นให้เปลี่ยนไปใช้อย่างอื่น
      แผนกอื่นในบริษัทมี svn อยู่บ้าง แต่ก็แค่นั้น
      ระบบควบคุมเวอร์ชันไม่ได้เปลี่ยนเร็วขนาดนั้น
      เครื่องมือในรายการก่อนที่ระบบควบคุมเวอร์ชันแบบกระจายจะเกิดขึ้นนั้น จริง ๆ แล้วมีจุดร่วมกันมาก และ git น่าจะยังอยู่ไปอีกนาน
    • อินเทอร์เน็ตมีแนวโน้มที่จะ ตรึง บางสิ่งไว้
      ในประวัติศาสตร์เคยมีหลายภาษาที่ครองอำนาจ แต่ภาษาอังกฤษจะกลายเป็นภาษาสุดท้าย เคยมีภาษาสคริปต์หลายภาษา แต่ javascript จะกลายเป็นภาษาสุดท้าย และเคยมีโปรโตคอลเครือข่ายหลายแบบ แต่ TCP/IP จะกลายเป็นโปรโตคอลสุดท้าย
      ผมมองว่า git ก็เป็นแบบเดียวกัน
      สิ่งที่อาจผลัก git ออกไปได้ คงมีแค่กรณีที่สภาพแวดล้อมสำหรับโปรแกรมเมอร์หน้าใหม่มีระบบควบคุมเวอร์ชันของตัวเองติดมาด้วย เช่น glitch[1]
      [1]: https://medium.com/glitch/reinventing-version-control-with-g...

  • ผมคิดว่าเหตุผลที่ git มีชื่อเสียงไม่ดีคือไม่มีใคร ตกลงกันได้เรื่องวิธีใช้
    แค่ดู GitHub PR กับการ push branch, rebase กับ merge ก็เป็นเครื่องมือที่ทำสิ่งเดียวกันโดยพื้นฐาน แต่ทำด้วยวิธีที่ต่างกันโดยสิ้นเชิง
    ปัญหาคือไม่มีฝ่ายไหนผิด
    การ rebase คอมมิตเล็ก ๆ ช่วยลดความซับซ้อนที่ไม่จำเป็นในประวัติ ส่วน merge จะรักษาสิ่งที่เกิดขึ้นจริงไว้ ช่วยให้เข้าใจเหตุผลของการเปลี่ยนแปลง
    แน่นอนว่า reverse merge นั้นแย่ที่สุด แต่นั่นก็เป็นปัญหาปวดหัวอีกเรื่องหนึ่ง
    เวลา push ไปยัง branch อาจไม่ต้อง force push เลยก็ได้ แต่กับ PR branch มักจะต้อง force push เสมอ
    แม้แต่เรื่องง่าย ๆ ก็สร้างรอยร้าวที่แก้ไม่ได้
    ผมเรียนมาว่า repository หลักคือ origin ส่วน fork ของผมคือ fork แต่บางคนเรียนมาว่า repository หลักคือ upstream และ fork ของตัวเองคือ origin
    ทั้งสองแบบไม่ได้ผิดเสมอไป แต่ถ้า origin สามารถหมายถึงตำแหน่งที่ต่างกันโดยสิ้นเชิงสองแห่ง การสื่อสารให้ชัดเจนก็ยากมาก

    • ถ้าดัดแปลงคำพูดของ Bjarne Stroustrup ระบบควบคุมเวอร์ชันมีอยู่แค่สองประเภท: แบบที่ผู้คนบ่น กับแบบที่ไม่มีใครใช้
    • ปรัชญาที่ช่วยได้คือ “ทำสิ่งที่เหมาะกับเป้าหมายเฉพาะหน้าตอนนี้ แล้วค่อยประเมินใหม่และปรับตัว”
      ในทางปฏิบัติ ผม rebase คอมมิตใน PR อย่างจริงจัง โดยโฟกัสแค่ว่า “อะไรจะทำให้รีวิวง่ายที่สุด?”
      พอรีวิวเสร็จ ก็ถามว่า “รูปแบบไหนจะดูแลและทำความเข้าใจได้ง่ายที่สุดในอนาคต?” แล้วอาจ squash ทั้งหมด หรือจัดโครงสร้างใหม่เป็นชิ้นส่วนที่ deploy แยกกันได้เพื่อให้ rollback ง่าย
      ประเด็นสำคัญคือ งานเหล่านี้อาจมีความต้องการต่างกัน และใช้วิธีต่างกันในแต่ละช่วงเวลาก็ไม่เป็นไร
      เพียงแต่ต้องใช้วิจารณญาณส่วนบุคคลมากขึ้น และสอนรวมถึงบังคับใช้กับทีมใหญ่ทั้งทีมได้ยาก
    • การแยก ความไม่สอดคล้องแบบโลคัล กับ ความไม่สอดคล้องทางสังคม เป็นเรื่องสำคัญ
      แบบแรกคือสิ่งที่ไม่กระทบคนอื่น
      เช่น จะตั้งชื่อ remote repository เป็น origin กับ upstream หรือเป็น fork กับ origin เพื่อนร่วมงานก็ไม่เดือดร้อน
      แบบหลังคือสิ่งที่ต้องประสานกับคนอื่น
      เช่น ประเด็นว่าจะเหลือประวัติ git สุดท้ายไว้ในรูปแบบใด
    • เหตุผลที่ git มีชื่อเสียงไม่ดีคือ command-line interface มันยุ่งเหยิงอย่างน่ากลัว
      ถ้า Apple เป็นผู้ออกแบบ command-line interface ของ git ผมว่าประสบการณ์ผู้ใช้จะดีขึ้นเป็นพันล้านเท่า และความทรงพลังจะลดลงแค่ประมาณ 10%

  • ก็ดีที่ Fossil เหมาะกับพวกเขา แต่ประโยคนี้ทำให้รู้สึกขัดใจ: “Fossil เป็นไบนารีปฏิบัติการแบบเดี่ยวที่เป็นอิสระในตัวเอง ติดตั้งได้แค่เอาไปไว้ใน $PATH และในไฟล์เดียวกันนั้นมีทั้งฟังก์ชันหลักของ Git และฟังก์ชันแบบ GitHub/GitLab ทั้งหมด…”
    ถึง git จะมีปัญหาหลายอย่าง แต่ก็ไม่ใช่แนวทางแบบ ยัดทุกอย่างรวมถึงอ่างล้างจานเข้าไปด้วย
    ผมชอบแนวทาง “ทำอย่างเดียวให้ดี” มากกว่า

    • ที่จริง Git เองก็รวมหลายอย่างที่คนทั่วไปไม่ค่อยรู้ไว้ด้วย
      เช่น ถ้ารัน git instaweb ก็จะเปิดเซิร์ฟเวอร์ CGI ในเครื่องกับสคริปต์ Perl CGI เพื่อให้เว็บ UI แบบเรียบง่ายมาก: https://git-scm.com/docs/git-instaweb
      ในแง่นี้ก็ไม่ได้ต่างจากฟังก์ชันหลักของ Fossil มากนัก
      ใน git ยังมีฟังก์ชัน การเชื่อมต่อกับไคลเอนต์อีเมล อยู่มากมาย ซึ่งคนที่ใช้แต่ GitHub อาจไม่รู้ด้วยซ้ำว่ามีอยู่ หรือมีไว้ทำไม
      เช่น git send-email ที่ส่งแพตช์ทางอีเมลได้จาก git โดยตรง: https://git-scm.com/docs/git-send-email
    • ความคิดที่ว่าสามารถแยก “สิ่งเดียว” ออกมาอย่างโดดเดี่ยวได้ และสิ่งนั้นไม่ใช่ “ชุดของสิ่งอื่น ๆ” เอง เป็นมายาคติที่ค่อนข้างเป็นอันตรายในโลกโปรแกรมมิง
      ทุกอย่างเป็นองค์ประกอบผสม ทุกอย่างเป็นไพป์ไลน์ของคำสั่ง และถูกสร้างจากหลายสิ่ง
      “งานที่ต้องทำ” ไม่ใช่สิ่งสัมบูรณ์ แต่ขึ้นอยู่กับมุมมองของผู้มอง
      หลักความรับผิดชอบเดียว ใช้กับความเป็นจริงตรง ๆ ไม่ได้ เป็นเพียงการประนีประนอมเพื่อรักษาสมดุลระหว่าง cohesion กับ modularity เท่านั้น
      จะตัดตรงไหนแล้วเรียกว่า “หนึ่ง” ก็ขึ้นอยู่กับเราและความต้องการของเรา
      สำหรับหลายคน เครื่องมือของ GitHub ถูกผสานอยู่ในเวิร์กโฟลว์มากเสียจนใช้ Git อย่างเดียวแทบไม่ได้เลย
      สำหรับพวกเขา GitHub คือ “สิ่งเดียว” และ SQLite ก็มี “สิ่งเดียว” ในแบบของ SQLite เอง
    • SQLite ยอดเยี่ยม และ Richard ก็เป็นอัจฉริยะอย่างไม่ต้องสงสัย แต่การยึดติดกับ โมโนลิธไบนารีไฟล์เดียว นั้นผมรู้สึกแปลกอยู่เสมอ
      อย่างที่บอก มันขัดกับปรัชญายูนิกซ์ที่ว่าให้ทำสิ่งเดียวให้ดี
      สำหรับผม การแบ่งระบบออกเป็นคอมโพเนนต์ที่ภายหลังสามารถเปลี่ยนหรือแก้ไขได้อย่างอิสระนั้นชัดเจนว่าสะอาดกว่า
    • ในสภาพแวดล้อม *nix ดั้งเดิม git ไม่ได้ยัดทุกอย่างรวมถึงอ่างล้างจานเข้าไปด้วย แต่ Git สำหรับ Windows ทำแบบนั้น
      ตัวติดตั้งใหญ่กว่า 50MB และถ้าจำไม่ผิดยังรวมเทอร์มินัลมาด้วย
      ในทางกลับกัน Fossil มีไบนารีปฏิบัติการแบบสแตนด์อโลนขนาด 3.3MB ให้ดาวน์โหลดตามแต่ละแพลตฟอร์มที่รองรับ
    • เพราะ git ไม่ได้รวมสิ่งเหล่านั้นไว้ จึงเกิดการ พึ่งพา GitHub หรือ GitLab เพื่อเติมชิ้นส่วนที่ขาด ซึ่งจริง ๆ แล้วจำเป็นต่อระบบจัดการซอร์สโค้ดสมัยใหม่

  • https://git-man-page-generator.lokaltog.net เป็นสิ่งที่ตลกที่สุดที่ได้เห็นมาพักใหญ่

    • คำอธิบายของ git-erase-working-tree ที่ว่า “ลบ working tree ปัจจุบันของ upstream root และ config อย่างระมัดระวัง และควรใช้เมื่อต้องการ quiltimport ไปยัง GUI ที่ active” ฟังดูมีประโยชน์ดี
    • git-molest-head ที่ว่า “ใช้ remote index เพื่อรบกวน upstream head อย่างผิด ๆ และทำ hook ที่เหมาะสมเพื่อจัดทำตารางของ head ที่กำหนด” นี่ออกจะยั่วยุเกินไปหน่อย
    • ผมใช้เวลานานเกินไปกว่าจะรู้ว่านี่ไม่ใช่ของจริง
      Git มีคำสั่งที่ดูเคอะเขินอยู่แล้ว ตอนนี้เลยไม่แปลกใจอะไรแล้ว
    • คำสั่งที่ชอบคือ git-tease-chain, git-scrub-dangling-object, git-seize-mailmap, git-dress-graft, git-strangle-tree, git-satisfy-daemon, git-pat-tree-object
    • ฟังดูไม่ค่อยสมจริงเท่าไร
      ถ้าจะให้เพ้อเจ้อได้ดีกว่านี้ต้องโรยผง LLM เพิ่มอีกหน่อย

  • การอภิปรายก่อนหน้านี้:
    ปี 2021, 356 ความคิดเห็น: https://news.ycombinator.com/item?id=29125934
    ปี 2018, 608 ความคิดเห็น: https://news.ycombinator.com/item?id=16806114
    น่าจะมีมากกว่านี้อีก แต่เอกสารเดียวกันถูกพบได้หลายเส้นทาง ทั้งแบบไม่มีโดเมน www, แบบไม่มีพาธ /drafts/, และแบบไม่มีพาธ /matrix/ ทำให้หากระทู้เก่าก่อนหน้านี้ยากขึ้น

  • ในนี้ก็มีคำวิจารณ์ Git ที่สมเหตุสมผลอยู่ แต่บางข้อก็ดูแปลกไปหน่อย
    ผมเคยใช้ Git ในหลายสถานการณ์ ตั้งแต่ repo ส่วนตัวในเครื่องไปจนถึง repo ของบริษัทขนาดใหญ่มาก ๆ แต่พูดตรง ๆ คือปัญหาเหล่านี้ประมาณครึ่งหนึ่งผมไม่เคยเจอเลย
    อย่างส่วนที่ว่า “network เรนเดอร์ช้า มีรายละเอียดน้อยกว่ามาก และแทบใช้งานไม่ได้บนมือถือ” ก็เช่นกัน และผมหวังว่าวันที่ทีมเราต้องมองว่า อุปกรณ์มือถือ เป็นวิธีตรวจสอบสถานะ branch จะไม่มีวันมาถึง
    ผมนึก use case แบบนั้นไม่ออกด้วยซ้ำ
    สำหรับคนอื่น ๆ มันเกิดขึ้นบ่อยไหม?

    • เกิดขึ้นตลอด
      ผมว่าการสำรวจโค้ดอย่างน้อย 50% ทำบนโทรศัพท์
      ผมใช้เว็บอินเทอร์เฟซ GitHub บนมือถือเยอะมากเพื่อสิ่งนี้ และการรองรับการค้นหา reference ช่วยได้มากจริง ๆ
      การค้นหายังไม่ค่อยดี และผมไม่ชอบที่อาการหน่วงแบบ SPA คอยทำให้การค้นหาในหน้าแบบพื้นฐานพังอยู่เรื่อย ๆ
      เวลาต้องคุ้ยโค้ด Firefox ผมใช้ Searchfox [0] ซึ่งเร็วและยอดเยี่ยม แทบไม่มีอะไรให้บ่น
      แต่ blame บนมือถือยังปรับปรุงได้อีกหน่อย
      เพิ่มบริบทคือผมเป็นนักศึกษาปริญญาโท ทำวิจัยด้านภาษาโปรแกรมและระบบ และเวลาส่วนตัวก็แฮ็ก IoT อยู่พอสมควร
      แล้วแต่จะขีดเส้นแบ่งรุ่นไว้ตรงไหน ผมอาจเป็น Gen Z ที่อายุมาก หรือ Millennial ที่อายุน้อยที่สุดเท่าที่เป็นไปได้
      [0] https://searchfox.org
    • ผมเคยลองเปิดดูโปรเจกต์บนรถไฟไปกลับที่ทำงาน เพื่อ ยืดเวลาทำงาน
      ถ้าไม่นับสัญญาณข้อมูลที่ไม่เสถียร GitHub ก็ทำงานได้ดี และการรีวิวโค้ดเบา ๆ ก็ทำได้ง่าย
      GitHub pulse[1] เป็น UI ที่ดีสำหรับดู activity ล่าสุด
      mirror ของ SQLite ไม่ได้ทำงานบน GitHub เลยมีแค่ประวัติ commit และหน้านี้ว่างอยู่ แต่โปรเจกต์ Caddy ที่ลิงก์ไว้เป็นตัวอย่างที่ดีกว่า
      โดยส่วนตัวผมว่ามันดูมีประโยชน์กว่า timeline
      อยากรู้ว่ามีใครทำมุมมองเทียบเท่าสำหรับ git/GitHub ไว้แล้วหรือยัง
      ดูไม่น่าจะยากนัก
      [1] https://github.com/caddyserver/caddy/pulse
    • ผมใช้ git จัดการบล็อกอยู่
      ผมทำ editor บน Android เพื่อแก้ไขผ่าน GitHub และต่อมาก็แก้ให้ทำงานกับ GitLab ได้ด้วย
      มีหลายเหตุผล แต่ส่วนใหญ่เป็นเพราะ git ไม่ว่าจะบน GitHub หรือ GitLab นั้น แทบใช้บนมือถือไม่ได้
      ตรวจสถานะได้ แต่ทำอะไรเกินกว่านั้นแทบยาก
      บทความนี้โดนใจผมมากในด้านอื่น ๆ ด้วย
      ทั้งที่ผมเคยเขียนหนังสือของ O’Reilly เกี่ยวกับ GitHub แต่ใช้ git มากว่า 10 ปีแล้วก็ยังรู้สึกว่ายังไม่เข้าใจมันทั้งหมด
      ข้อสังเกตในนี้ผมเห็นด้วย
    • ไม่มีเหตุผลอะไรที่ฟีเจอร์นั้นไม่ควรทำงานบนมือถือ
      ถ้าออกแบบและ implement ดีกว่านี้ มันก็ควรทำงานบนมือถือได้แน่นอน
      ผู้คนเข้า GitHub บนมือถือบ่อย ๆ ด้วยเหตุผลเดียวกับที่เข้า GitHub จากแพลตฟอร์มอื่น
      ผมเองก็เคยทำแน่นอน
      ข้อสังเกตเหล่านี้เกี่ยวกับ git ไม่ได้เป็น “ปัญหา” เสมอไป แต่ใกล้เคียงกับ การตัดสินคุณค่าของฟีเจอร์ มากกว่า
      คุณอาจเห็นด้วยหรือไม่เห็นด้วยก็ได้ และไม่จำเป็นต้องเป็นสิ่งที่ต้องเจอเองเท่านั้น
    • มีหลายวิธีที่แม้จะไม่ใช่วิธีที่ดีที่สุด แต่ก็มีคุณค่าเมื่อปล่อยให้เป็นตัวเลือก และการที่ตัวเลือกเหล่านั้นทำงานได้ดีที่สุดเท่าที่จะทำได้ย่อมดีกว่าไม่มีตัวเลือกเลย
      เหมือนเป็นความต่างระหว่างการลดทอนประสิทธิภาพอย่างค่อยเป็นค่อยไปกับการล้มเหลวทันที
      ต่อให้ตัวเลือกชั้นเลิศที่ทำมาอย่างประณีตจะดีแค่ไหน ถ้ามันเป็นตัวเลือกเดียว มันก็เปราะบาง และดังนั้นจึงห่วย

  • ไม่กี่วันก่อนผมดูวิดีโอที่อธิบายทางเลือกแทน Git และแน่นอนว่า Fossil ก็เป็นหนึ่งในนั้น
    ผมเคยใช้ Fossil ในบางโปรเจกต์ ก็ถือว่าโอเค
    Pijul https://pijul.org/ ที่อธิบายใน presentation นี้น่าสนใจมาก และเคยมีการคุยกันใน HN มาก่อนแล้ว
    ที่มา: https://www.youtube.com/watch?v=M4KktA_jbOE

    • ผมยังพยายามทำความเข้าใจอยู่ แต่ jj ก็น่าสนใจเช่นกัน: https://github.com/martinvonz/jj
    • Pijul น่าหลงใหลเสมอมา
      ให้ความรู้สึกเหมือน จอกศักดิ์สิทธิ์ ของ version control
      แต่ในโปรเจกต์ส่วนตัวผมก็พัฒนาเป็นเส้นตรงอยู่ดี และในที่ทำงานผมก็ควบคุมไม่ได้ว่าจะใช้อะไร เลยไม่เคยได้ใช้จริง
    • จะถือว่า Pijul พร้อมใช้งานได้ก็ต่อเมื่อรองรับ การส่ง patch ทางอีเมล เป็นทางเลือกทั่วไป เพื่อให้คนที่ไม่อยากสร้างบัญชีบริการเฉพาะยังส่ง patch ไปยัง upstream ได้

  • เคยลองใช้ Fossil กับโปรเจกต์โลคัลส่วนตัว
    มันเป็นระบบจัดการเวอร์ชันที่ค่อนข้างมีความสามารถ และเว็บ UI ก็ใช้ได้ดีทีเดียว
    แต่สิ่งที่ต้องระวังคือควรสำรองข้อมูล ฐานข้อมูลที่เก็บ SQLite ที่เป็นพื้นฐานไว้บ่อย ๆ
    หลังจากอัปเกรด Fossil แล้วคอมมิตไปไม่กี่ครั้ง เผลอไปคอมมิตด้วย Fossil เวอร์ชันเก่ากว่า ทำให้ฐานข้อมูลที่เก็บของ Fossil เสียหายจนกู้คืนไม่ได้ และสูญงานไปหลายวัน
    ตลอด 10 ปีที่ใช้ Git ทุกวัน ไม่เคยมีครั้งไหนที่ Git ทำที่เก็บเสียหายเพราะต่างเวอร์ชันเลย

    • ขอยกเป็นตัวอย่างโต้แย้งว่า ผมใช้ Fossil แบบโหดสุด ๆ มาตลอด
      บนระบบต่าง ๆ มีเวอร์ชันที่ต่างกันเป็นปี ๆ อยู่ตามใจชอบ และก็ใช้ไบนารีที่มีอยู่ตอนตั้งค่าระบบนั้นต่อไปเรื่อย ๆ
      มีทั้ง macOS, Linux หลายสาย, กล่อง FreeBSD และถ้าย้อนกลับไปไกลกว่านั้นก็น่าจะเคยมี Windows ด้วย
      ซิงก์กันระหว่างเครื่องเหล่านี้แบบแก้ขัดเฉพาะหน้า
      ที่เก็บบางอันอายุมากกว่า 10 ปีแล้ว อันหนึ่งมีคอมมิตเกิน 10,000 ครั้ง และอีกอันเช็กอินสภาพแวดล้อมการพัฒนาทั้งชุดจนมีขนาดหลาย GB
      บางครั้งมันบอกว่าต้อง rebuild ใหม่ และทุกครั้งก็สำเร็จ
      ถ้าเจอพิมพ์ผิดระหว่างคอมมิต ผมก็มักกด ctrl-c ยกเลิกตามนิสัย
      แต่ถึงอย่างนั้นมันก็ไม่เคยทำให้ผิดหวังเลยสักครั้ง
      Fossil เป็น โปรแกรมที่เชื่อถือได้มากที่สุด แบบทิ้งห่าง ในบรรดาโปรแกรมที่ผมเคยใช้มา
    • ผมเห็นด้วยกับข้อกล่าวอ้างนั้นยาก
      รูปแบบ artifact พื้นฐานของ Fossil เข้ากันได้ตั้งแต่แรกจนถึงปัจจุบัน
      มีการปรับปรุงก็จริง แต่ไม่มีการเปลี่ยนแปลงที่ทำให้พัง และในหมู่ผู้ใช้ Fossil Forum จำนวนมากก็ไม่มีรายงานความเสียหายแบบนั้น
      ถ้าให้เดา น่าจะเป็นสถานการณ์ที่เช็กอินบางอย่างด้วย Fossil รุ่นใหม่โดยใช้ฟีเจอร์ที่ปรับปรุงใหม่ แล้วพยายามดึงออกด้วย Fossil รุ่นเก่าที่ไม่เข้าใจฟีเจอร์ใหม่นั้น จึงได้รับข้อผิดพลาด
      เช่น ตอนแรก Fossil ใช้เฉพาะแฮช SHA1 แต่หลังการโจมตี SHAttered ก็ได้รับการปรับปรุงให้รองรับทั้ง SHA1 และ SHA3
      แน่นอนว่านี่เป็นแค่การคาดเดา แต่ดูเป็นไปได้มากที่สุด
      ผมไม่เคยทำแบ็กอัปล้วน ๆ เลยแม้แต่ครั้งเดียว สำหรับที่เก็บ SQLite, ที่เก็บ self-hosting ของ Fossil เอง และที่เก็บ Fossil กว่า 100 แห่งที่มีอยู่
      เพื่อรับมือภัยพิบัติ ผมทำ clone ไว้บนเครื่องอื่น
      จริง ๆ แล้วมี cron job บนเครื่องหลายแห่งทั่วโลกที่คอย sync ที่เก็บ Fossil สำคัญ ๆ อย่าง SQLite ทุกชั่วโมง
      แต่แบ็กอัปแบบล้วน ๆ ไม่เคยทำเลยสักครั้ง
      เมื่อหลายปีก่อน ที่เก็บ SQLite หลักเคยเสียหายครั้งหนึ่ง
      ด้วยเหตุบังเอิญ file descriptor 2 ถูกปิด และตอนเปิดฐานข้อมูล SQLite ที่เป็นที่เก็บ มันถูกเปิดเป็น file descriptor 2
      หลังจากนั้นบั๊กบางอย่างใน Fossil ทำให้เกิด assert() แล้วเขียนลง file descriptor 2 จนทับข้อมูลบางส่วนของฐานข้อมูล
      เรากู้คืนที่เก็บจาก clone แก้ข้อบกพร่องของ assertion ใน Fossil และเพิ่มความแข็งแรงให้ SQLite ไม่ใช้ file descriptor ที่น้อยกว่า 3
      เอกสารที่ควรดูประกอบ: https://fossil-scm.org/home/doc/trunk/www/selfcheck.wiki
    • นี่เป็นพฤติกรรมที่รู้กันอยู่แล้วหรือเปล่า?
      ถ้าคิดถึง แนวทางด้านความน่าเชื่อถือ ของนักพัฒนา SQLite ก็น่าจะมองว่าเป็นบั๊กร้ายแรงที่ควรแก้ไข
    • ผมเคยเจอที่เก็บ git เสียหายเหมือนกัน
      แต่โดยปกติแล้วไม่ได้กู้คืนไม่ได้

  • ว้าว เรื่องนี้ทำให้ผมดำดิ่งไปอ่านยาวเลย
    น่าจะเป็นหนึ่งในสิ่งที่ดีที่สุดที่ได้เห็นมาพักใหญ่
    ดูเหมือนจะใช้ Fossil แล้ว mirror ไปยัง Git/GitHub ได้ด้วย: https://fossil-scm.org/home/doc/trunk/www/inout.wiki
    UI ในตัวดูใช้ได้ดี และใช้งานได้จริง รวมถึงนำทางง่าย
    แต่ผมหวังว่า UI จะรองรับการคอมมิตด้วย ซึ่งหาไม่เจอ
    แบบนั้นจะได้ไม่ต้องสลับใช้บรรทัดคำสั่งกับเว็บอินเทอร์เฟซเพื่อทำงานให้เสร็จ
    ถ้าสามารถทำ wrapper UI บน Fossil ที่รองรับ open, init, commit, sync, sync-with-git, start-web-interface ได้ หรือใส่เข้าไปใน Fossil เองได้ ก็น่าจะมีประโยชน์มากสำหรับคนที่ไม่ค่อยถนัดเทคนิคหรือไม่ใช่นักพัฒนาแต่ต้องจัดการโค้ด เช่น คนสายชีววิทยา คณิตศาสตร์ วิทยาการข้อมูล ที่ใช้จัดการ Jupyter notebook เป็นต้น
    แน่นอนว่าไคลเอนต์ UI ของ git แบบเรียบง่ายก็ใช้เพื่อจุดประสงค์นั้นได้เหมือนกัน แต่ก็จะเสียวิกิและตั๋วงานในตัวไป
    ความสามารถในการทำงานบนเครื่องโลคัลก็มีประโยชน์ แต่ git ก็ทำได้เช่นกัน
    อย่างไรก็ดี ผมเคยเห็นคนที่ไม่ค่อยถนัดเทคนิคไม่อยากใช้ git หรือแม้แต่การจัดการเวอร์ชันโดยรวม
    ผมมองเห็นศักยภาพของการมี วิกิและตั๋วงานในตัว อยู่ในที่เก็บเดียวกัน
    การมีไฟล์ที่ต้องแบ็กอัปเพียงไฟล์เดียวก็น่าสนใจด้วย

  • สำหรับนักพัฒนาซอฟต์แวร์ ระบบจัดการเวอร์ชัน เป็นเครื่องมือแบบเดียวกับ IDE หรือระบบปฏิบัติการพื้นฐาน
    ยิ่งต้องไปจุกจิกกับเครื่องมือพวกนี้น้อยเท่าไร ก็ยิ่งมีประสิทธิภาพมากขึ้นเท่านั้น
    จากมุมของคนที่เคยใช้ระบบจัดการเวอร์ชันมาหลายตัว Fossil อยู่ใน sweet spot ที่สมบูรณ์แบบสำหรับผม
    พูดตรง ๆ คือตั้งค่าไว้แล้วก็ลืมมันไปได้เลย