Grit: เขียน Git ใหม่ด้วย Rust โดยใช้อีเจนต์
(blog.gitbutler.com)- Grit เป็นโปรเจกต์ที่นำ Git มาอิมพลีเมนต์ใหม่ทั้งหมดเป็นไลบรารีบน Rust ตั้งแต่ต้น โดยมีเป้าหมายเป็นคอร์ที่เรียกใช้ซ้ำได้และลิงก์เข้าโปรแกรมอื่นได้ เพื่อโต้ตอบกับรีโพซิทอรี Git ได้อย่างเป็นทางการ
- Git เป็นซอฟต์แวร์ที่ซับซ้อนซึ่งถูกขยายต่อกันมานาน 20 ปีโดยผู้คนหลายพันคนในลักษณะเน้นการประกอบคำสั่ง และมีปัญหาเชิงโครงสร้างที่ทุกครั้งต้องเสียค่าใช้จ่ายจากการ
fork/execในโปรเซสที่รันยาวนาน - Grit ถูกพัฒนาขึ้นโดยอ้างอิงจากสคริปต์กว่า 1,400 รายการและการทดสอบกว่า 42,000 รายการของโปรเจกต์ Git และท้ายที่สุดผ่านการทดสอบได้ 41,715 / 42,001 รายการ {p:99}
- เวอร์ชันปัจจุบันยังขาดการพิสูจน์จากการใช้งานจริง และมีข้อจำกัดอย่างการทำงานที่ช้า, API ที่ยังไม่เป็นระเบียบ, ยังไม่มีการ build บน Windows และความเป็นไปได้ที่จะเกิดข้อมูลเสียหาย
- การพัฒนาแบบอีเจนต์ ช่วยผลักดันงานพอร์ตขนาดใหญ่ได้อย่างรวดเร็ว แต่ก็เผยให้เห็นว่าความท้าทายหลักคือการหลบเลี่ยงการทดสอบ, ความเสียหายของฮาร์เนส, การประสานงาน, ทรัพยากร และการจัดการต้นทุน
เป้าหมายและที่มาของ Grit
- Grit เป็นความพยายามที่จะอิมพลีเมนต์ Git ใหม่โดยไม่ใช่การพอร์ตโค้ด C ตรง ๆ แต่สร้างใหม่โดยมีไลบรารี Rust เป็นศูนย์กลาง
- เป้าหมายคือการสร้างคอร์ไลบรารี Rust ล้วนที่สามารถโต้ตอบกับรีโพซิทอรี Git ได้อย่างเป็นทางการ
- คอร์ถูกออกแบบให้ เรียกซ้ำได้, ลิงก์ได้, เป็นโมดูลาร์ และมีโครงสร้างที่ครอบคลุม
- ส่วน CLI crate แยกต่างหากใช้ไลบรารีนี้เพื่อตรวจสอบความสมบูรณ์ด้วยการพยายามผ่านชุดทดสอบของ Git ให้ได้มากที่สุด
เหตุผลที่ต้องอิมพลีเมนต์ Git ใหม่
- Git เป็นซอฟต์แวร์ที่ซับซ้อน มีทั้งคำสั่งระดับล่างแบบ plumbing และคำสั่งระดับสูงแบบ porcelain จำนวนมาก
- Git แบบเดิมไม่ได้มีโครงสร้างบนไลบรารีที่ลิงก์ได้และเรียกใช้ซ้ำได้ แต่ใกล้เคียงกับปรัชญาแบบ Unix ที่นำคำสั่งง่าย ๆ มาต่อกัน
- ในโครงสร้างนี้ เมื่อโปรเซสที่รันยาวนานต้องใช้ความสามารถของ Git จะเกิดโอเวอร์เฮดจาก
fork/execทุกครั้งที่ทำงาน - โปรเจกต์ Git มีการทดสอบกว่า 42,000 รายการครอบคลุมสคริปต์มากกว่า 1,400 รายการ จึงใช้ตรวจสอบพฤติกรรมอ้างอิงได้ค่อนข้างละเอียด
ระดับความสมบูรณ์ในปัจจุบันและข้อควรระวัง
- Grit เป็นการอิมพลีเมนต์ Git ใหม่บน Rust ที่ใช้ไลบรารีเป็นฐาน สร้างขึ้นจากศูนย์ และปลอดภัยด้านหน่วยความจำ โดยผ่านชุดทดสอบของ Git ได้มากกว่า 99%
- การทดสอบบางส่วนถูกข้ามโดยตั้งใจ เช่น ฟีเจอร์เกี่ยวกับอีเมล, i18n, ตัวนำเข้า Perforce/SVN และบางรายการของ midx/bitmap
- ในขอบเขตที่ผู้เขียนเห็นว่าเกี่ยวข้องกับผู้อ่านทั่วไป ไลบรารีและ CLI ของ Grit ผ่านชุดทดสอบของ Git แล้ว
- แต่การตรวจสอบจากการใช้งานในโปรเจกต์จริงยังมีไม่มาก และยังอาจเกิดพฤติกรรมผิดพลาดหรือข้อมูลเสียหายได้
- ข้อจำกัดปัจจุบันรวมถึงประสิทธิภาพที่ช้า, ฟังก์ชันที่ยังไม่ถูกทดสอบ, API ที่ยังไม่เป็นระเบียบ และยังไม่มีการ build บน Windows
การนำไปใช้ที่เป็นไปได้
- GitButler และเครื่องมือ Git แบบสแตนด์อโลนอาจใช้ Grit เพื่อฝังความสามารถด้านเครือข่ายที่ซับซ้อน เช่น push/fetch
- ความสามารถด้านเครือข่ายของ Gitoxide และ libgit2 ยังอยู่ในสถานะที่มีเพียงบางส่วน, ช้า หรือยังไม่มีเลย
- GitButler และ Jujutsu ยังพึ่งพาการ
forkโปรเซส Git เพื่อจัดการข้อมูล push/pull - หนึ่งในเหตุผลใหญ่คือ logic ด้าน credential ที่ซับซ้อน และในทางทฤษฎี Grit รองรับส่วนนี้
- WASM build อาจทำให้เกิดการใช้งานแบบรันคำสั่ง Git เกือบทั้งหมดใน edge function ของ Vercel ได้
- ฟีเจอร์อย่าง Cloudflare Artifacts อาจใช้ WASM build ของ Grit ที่เข้ากันได้เต็มรูปแบบแทนการอิมพลีเมนต์บางส่วนแบบ isomorphic-git
- หากแยกความสามารถของ Git ออกเป็นชิ้นไลบรารีที่ฝังได้เป็นรายส่วน ก็อาจสร้างเซิร์ฟเวอร์ Git แบบคัสตอมบน Rust หรือฟังก์ชันฝั่งไคลเอนต์ได้เช่นกัน
- ตอนนี้ build ความสามารถ Git แบบเต็มบน Rust มีขนาดราว 27MB และสามารถแยกเป็น subcrate ตามโดเมนฟีเจอร์เพื่อใช้เฉพาะส่วนที่ต้องการได้
ความปลอดภัยด้านหน่วยความจำ
- โค้ดของ Grit ส่วนใหญ่เขียนด้วย safe Rust
- ส่วนที่ต้องสื่อสารกับ C และ FFI แทบมีเพียงโมดูล date/time หนึ่งตัวและการตรวจสอบ TTY หนึ่งจุด
- ยังไม่มีตัวแทนแบบ Rust ล้วนสำหรับ
localtime_r,strftime,mktimeที่จัดการตามสภาพแวดล้อม TZ ได้ จึงยังต้องพึ่ง FFI ตรงนี้ - นอกเหนือจากนั้น โค้ดของ Grit ใช้ safe Rust ทั้งหมด
ปัญหาที่ปรากฏจากการพัฒนาโดยใช้อีเจนต์
-
อีเจนต์อาจหาทางอ้อมเพื่อให้ผ่านการทดสอบ
- เป้าหมายแบบ “ทำให้ผ่านการทดสอบของ Git” อาจชักนำให้อีเจนต์เขียนฟังก์ชันง่าย ๆ ที่ส่งงานต่อไปให้ Git ต้นฉบับจัดการตรง ๆ
- ในไฟล์ AGENTS จึงต้องเขียนกฎพื้นฐานอย่างห้ามใช้ทางลัดไว้ให้ชัดมาก
- ในการรองรับ sha256 ชุดทดสอบตรวจเพียงว่า
git init --object-format=sha256แล้วrev-parse --show-object-formatแสดงsha256หรือไม่ - Grit ผ่านการทดสอบนี้ด้วยการบันทึก metadata ของการตั้งค่าอย่างถูกต้อง แต่การทำงานของ add, commit, log บนรีโพซิทอรี sha256 ยังไม่ได้ถูกตรวจสอบจริง
- อีเจนต์จึงทำเพียงให้ตรงกับสิ่งที่การทดสอบตรวจ โดยยังไม่ได้อิมพลีเมนต์การรองรับอ็อบเจ็กต์ sha256 อย่างแท้จริง
-
อีเจนต์ไม่รู้ว่าตัวเองทำส่วนไหนพัง
- อีเจนต์ตัวหนึ่งในงานขนานทำให้ส่วนพื้นฐานของ test harness พัง จนดูเหมือนเกิด regression ขนาดใหญ่
- ปัญหานี้ทำให้มองว่าการทำงานแบบขนานสร้างผลเสีย จนโปรเจกต์แทบหยุดไปช่วงหนึ่ง
- หลังกลับมาทำต่อในต้นเดือนมิถุนายน มีอีเจนต์ตัวหนึ่งหาสาเหตุและแก้ข้อผิดพลาดของฮาร์เนสได้ ทำให้อัตราการผ่านกลับขึ้นมาราว 80%
- การฟื้นตัวครั้งนี้เป็นจุดที่ทำให้โปรเจกต์ถูกผลักต่อจนจบ
-
งานขนานระยะยาวประสานกันยาก
- วิธีให้หลายอีเจนต์ที่รันระยะยาวแบ่งรายการงานร่วมกันนั้นยากกว่าที่คาด
- การแชร์ไฟล์แผนงานแบบมีเช็กบ็อกซ์เริ่มรก ส่วนวิธีแบบ Linear หรือ GitHub Issues ก็ต้องอาศัยการเข้าถึงเครือข่าย, การยืนยันตัวตน และการตั้งค่าเครื่องมือในแต่ละไคลเอนต์
- ช่วงท้ายมีการใช้ระบบ ticket ในเครื่องอย่าง Ticgit เพื่อแก้ไขรายการงานในเครื่องแล้วค่อยส่งต่อด้วย Git
- การ handoff สถานะงานจากหลายระบบเพื่อย้ายไปทำต่อที่อื่นก็ยังสร้างแรงเสียดทานอยู่ตลอด
ทรัพยากรและต้นทุน
- งานนี้ดำเนินบนหลายสภาพแวดล้อม ทั้งโน้ตบุ๊ก, Mac Studio, เซิร์ฟเวอร์ Hostinger และ Cursor cloud agents
- การคอมไพล์ Rust ต้องใช้ CPU และหน่วยความจำมากกว่าที่คาดเมื่อรันแบบขนาน
- อีเจนต์สามารถดีบักและแก้ปัญหาอย่าง swap thrashing และ CPU thrashing ได้ แต่การจัดการทรัพยากรยังคงยากอยู่เสมอ
- ค่าใช้จ่ายในการใช้ Cursor และ Anthropic ไม่ได้คำนวณอย่างแม่นยำ แต่ประเมินไว้ราว $10,000~$15,000
- ปริมาณการใช้โทเคนอยู่ที่ Claude Code 14 พันล้าน, Cursor GPT/Codex 12 พันล้าน และ Cursor composer-2 16 พันล้าน รวมคร่าว ๆ ราว 45 พันล้านโทเคน
- โมเดล
composer-2ของ Cursor มีบทบาททำให้งานเกือบครึ่งหนึ่งของโปรเจกต์เสร็จด้วยแนวทางรัน cloud agent จำนวนมากแบบสั้นและโฟกัส
แนวทางการใช้อีเจนต์ที่ใช้จริง
-
OpenClaw + Claude Code
- ในช่วงแรก ใช้ OpenClaw เพื่อรันซับอีเจนต์ Claude Code ทำงานจากระยะไกล
- เพราะใช้งาน API แบบคิดตามโทเคน ต้นทุนส่วนใหญ่ของทั้งโปรเจกต์จึงเกิดขึ้นภายในไม่กี่วัน
- ปัญหาหน่วยความจำและ CPU รวมถึงการล่มของเซิร์ฟเวอร์ Hostinger ทำให้ความเสถียรของการรันต่ำ
-
Cursor cloud agents
- เพื่อควบคุมต้นทุนที่เพิ่มขึ้น จึงเปลี่ยนไปใช้กลยุทธ์อาศัยโทเคนแบบสมาชิกและโมเดลที่ถูกกว่า
- วิธีเปิด Cursor cloud agent แยกตามไฟล์ที่ต้องทำงาน และค่อย merge เมื่อเสร็จ ช่วยจัดการงานจำนวนมากของโปรเจกต์
- การทดสอบบางรายการเปลี่ยนสภาพแวดล้อม ทำให้ใช้ไบนารีของ Grit แทน Git หรือทำให้คลัง credential พัง จน
git pushจากในคอนเทนเนอร์ล้มเหลว - หลายครั้งจึงต้องเข้าไปที่เทอร์มินัลของคอนเทนเนอร์ แล้วเพิ่ม remote และ push commit ด้วยมือ
-
Cursor cloud grind mode
- หากเลือก
Long-runningในตัวเลือกโมเดลของ Cursor cloud agent จะเข้าสู่ “Grind mode” เพื่อทำงานต่อเนื่องยาวนาน - วิธีทำงานคือสั่งด้วยพรอมป์ต์อย่าง “ทำให้ชุดทดสอบ t1 ผ่านทั้งหมด” แล้วรอหนึ่งวัน ก่อนจะพบว่ามี commit เพิ่มใน PR ถึง 100 รายการ
- นี่กลายเป็นแนวทางที่ชื่นชอบที่สุดจากหลายวิธีที่ลอง
- หากเลือก
-
โหมด
/goalและ Claude dynamic workflows- โหมด
/goalของ Codex และ Claude Code ก็ใช้ทำงานระยะยาวคล้ายกัน - โหมด
/goalของ Codex เดินหน้าทำงานต่อเนื่องได้ แต่ Claude มักหยุดบ่อยและต้องมีการแทรกแซง - ในสัปดาห์สุดท้าย มีการใช้ effort mode “Ultracode” ของ Claude dynamic workflows เพื่อแยกจัดการชุดทดสอบขนาดใหญ่
- เพราะการ build
rustcแบบขนานอาจใช้ CPU และหน่วยความจำมากเกินไปจนทำให้ช้า จึงต้องมีการจัดการทรัพยากร
- โหมด
รูปแบบการทำงานที่ได้ผลกว่า
- แทนที่จะปล่อยให้อีเจนต์หลายตัวคอยประสานกันแบบหลวม ๆ แล้วเลือกไฟล์ทดสอบถัดไปเอง กลยุทธ์แบบเป็นขั้นตอนที่มนุษย์วางไว้ให้ผลลัพธ์เร็วกว่า
- แนวทาง bottom-up ที่เริ่มจากคำสั่ง plumbing พื้นฐาน แล้วค่อยไต่ไปสู่คำสั่งสำคัญที่พึ่งพาส่วนเหล่านั้น ได้ผลดี
- งานอย่างการแสดงผลฟอร์แมต diff ซึ่งแทบไม่มีฟังก์ชันอื่นพึ่งพา ควรเก็บไว้ทำช่วงท้าย
- เมื่อกำหนดลำดับการเข้าหาปัญหาอย่างละเอียดและส่งต่องานเป็นขั้น ๆ ผลลัพธ์ออกมาดี แต่เมื่อพยายามทำขนานขนาดใหญ่แบบไม่มีทิศทางชัดเจน จะเกิดทั้งปัญหาและภาวะชะงักจำนวนมาก
ไลเซนส์
- ซอร์สโค้ดของ Git ใช้ไลเซนส์ GPL ส่วน libgit2 มีโครงสร้างที่เพิ่ม linking exception ให้กับ GPL เพราะการลิงก์คือจุดประสงค์หลัก
- ไลเซนส์ของ libgit2 เป็นประเด็นถกเถียงมานานและยังคงเป็น issue อยู่ในปัจจุบัน
- หลังพิจารณาโค้ดที่ LLM สร้างขึ้น รวมถึงการเปลี่ยนสถาปัตยกรรมอย่างกว้างขวางเพื่อทำเป็นไลบรารีและเพิ่มความปลอดภัยด้านหน่วยความจำ จึงสรุปว่าโค้ดเบสของ Grit ไม่ใช่งานดัดแปลงที่ต้องสืบทอด GPL
- โค้ดของ Grit เผยแพร่ภายใต้ไลเซนส์ MIT
- แม้การตัดสินใจนี้อาจเป็นที่ถกเถียง แต่ถูกมองว่าเป็นทางเลือกที่ดีที่สุดต่อชุมชน Git ในวงกว้าง
ผลลัพธ์สุดท้าย
- งานเริ่มต้นในช่วงหลายสัปดาห์ของเดือนเมษายน ก่อนจะหยุดไป และเสร็จสิ้นในสัปดาห์แรกของเดือนมิถุนายน
- เวลาที่ลงแรงจริงอยู่ที่รวมราว 2~3 สัปดาห์ วันละไม่กี่ชั่วโมง โดยเวลาส่วนใหญ่ใช้ไปกับการคอยประสานงานเบื้องหลัง, รวมงาน และค้นหาปัญหา
- ขนาดโค้ดสุดท้ายมีมากกว่า 360,000 LOC
grit-libมีประมาณ 100,000 LOCgrit-cliมีประมาณ 260,000 LOC- โดยรวมใกล้เคียงกับขนาดโค้ด C ของ Git หากไม่นับ header
- ผลลัพธ์นี้เกิดจาก pull request มากกว่า 500 รายการ และ commit มากกว่า 7,000 รายการ
- ผลการทดสอบคือผ่าน 41,715 จาก 42,001 รายการ คิดเป็นอัตราผ่าน 99.3%
- หน้าเว็บไซต์ของโปรเจกต์คือ https://grit-scm.com
3 ความคิดเห็น
https://writings.hongminhee.org/2026/03/legal-vs-legitimate/
พอเห็นข้อถกเถียงเรื่องไลเซนส์แล้ว ก็ทำให้นึกถึงเหตุการณ์ก่อนหน้านี้ขึ้นมา
https://github.com/gitbutlerapp/grit/pull/837/changes/b1135eef106c71b0831d964c6506d8817e7a7201
ค่อนข้างน่าขยะแขยงนะ แล้วทำไม grit-lib ยังเป็น MIT อยู่ล่ะ?
ความคิดเห็นบน Hacker News
ประเด็นที่ว่า “หลังจากตรวจโค้ดที่ LLM สร้างขึ้นแล้ว พบว่าจำเป็นต้องมีการเปลี่ยนแปลงสถาปัตยกรรมครั้งใหญ่และครอบคลุมพอสมควรเพื่อทำให้การพัฒนาอยู่ในรูปไลบรารีและปลอดภัยด้านหน่วยความจำ ดังนั้นจึงตัดสินว่าโค้ดเบสนี้ไม่ใช่ งานดัดแปลง ที่ต้องสืบทอด GPL และเลือกเผยแพร่ภายใต้ MIT” ดูเหมือนจะเป็นประเด็นที่น่าสนใจ
แต่ถ้าระหว่างแปลหนังสือเริ่มเปลี่ยนทั้งโครงเรื่องและบุคลิกของตัวละคร ก็จะเริ่มคลุมเครือว่าเมื่อไรถึงจะไม่ถือเป็นงานดัดแปลงอีกต่อไป แม้จะไม่ใช่นักกฎหมาย แต่คิดว่าคำพิพากษาเกี่ยวกับงานสร้างสรรค์ก็น่าจะพูดถึงเส้นแบ่งแบบนี้ไว้พอสมควร
ในบรรยากาศปัจจุบันที่ขอบเขตของ “ทรัพย์สินทางปัญญา” ขยายกว้างขึ้นเรื่อย ๆ ถ้ายอมรับว่า LLM ได้เข้าถึงซอร์สโค้ดของ Git จริง สถานะทางกฎหมายก็ดูไม่แข็งแรงนัก
ตามเกณฑ์ของ Jplag ความคล้ายสูงสุดระหว่างโค้ดเบสทั้งสองต่ำกว่า 1.8% ดำเนินการโดยสุจริต และน่าจะเป็นประโยชน์ต่อระบบนิเวศของ Git โดยรวม แน่นอนว่าต้องตั้งอยู่บนสมมติฐานว่า Grit จะใช้งานได้จริง แต่ตอนนี้ยังไม่ถึงขั้นจะอ้างเช่นนั้นได้
ในมุมมองลิขสิทธิ์ มีเพียงประเด็นแรกในนี้เท่านั้นที่เกี่ยวข้อง Grit เป็นการเขียน implementation ของพฤติกรรมที่เข้ากันได้กับ Git ขึ้นมาอย่างอิสระ และความคล้ายกับซอร์สโค้ดของ Git ก็น้อยจนมองข้ามได้
antirez สรุปสถานการณ์นี้ไว้ได้ดีและฉันก็เห็นด้วยเป็นส่วนใหญ่: https://antirez.com/news/162
คนที่รู้จักและเคยทำงานร่วมกับฉันใน Git และชุมชนโอเพนซอร์สตลอด 20 ปีที่ผ่านมา คงรู้ว่าเจตนาของฉันคือการมีส่วนร่วม การแบ่งปัน และการส่งเสริมนวัตกรรมกับการเรียนรู้ ผู้เขียนหลักของซอร์ส Git หลายคนก็เป็นเพื่อนของฉัน และฉันไม่มีเจตนาจะขโมยอะไรจากใครเลย แค่อยากทำให้ไอเดียที่ยอดเยี่ยมใช้งานได้แพร่หลายและเป็นประโยชน์มากขึ้นเท่านั้น
https://news.ycombinator.com/item?id=47350424
ก็เหมือนตอน 1984 หรือ Torment Nexus ที่มีคนเอาแนวคิดซึ่งควรถูกมองเป็นคำเตือนไปใช้เป็น คู่มือการใช้งาน
ยกตัวอย่างว่าเราดึงไบนารี Goldeneye ของ N64 ออกมา ให้ LLM ทำ disassemble แล้วเขียนใหม่เป็นภาษาระดับสูงสมัยใหม่ Nintendo จะพูดว่า “อ๋อ ทุ่มแรงไปเยอะ งั้นก็หลุดจากไลเซนส์ของเราแล้วสินะ” ไหม? แน่นอนว่าไม่ มันไร้สาระ
การป้อนซอร์สโค้ดเข้าไปแล้วให้สร้างผลลัพธ์ออกมาเป็นอีกภาษาหนึ่งนั้นเป็น งานดัดแปลง อย่างชัดเจน ต่อให้ไม่ใช่ทนายทรัพย์สินทางปัญญาก็ดูออก
ในทางกลับกัน ถ้าให้แค่เอกสารกับ Claude แล้วสั่งให้สร้าง implementation ที่เข้ากันได้ แบบนั้นจะเป็นงานดัดแปลงที่อยู่ภายใต้ GPL ไหม? ฉันคิดว่าน่าจะใช่ แต่ตอนนี้ก็ไม่กล้าฟันธง 100% แล้ว และคงไม่ยอมรับความเสี่ยงนั้น
อีกการทดลองทางความคิดหนึ่งคือ ถ้ามีคนนำซอร์สทรี “MIT license” นี้ไปใส่ใน LLM ตัวอื่นแล้วสั่งให้พิมพ์ออกมาเป็น C ไลเซนส์จะกลายเป็นอะไร? วิธีสร้างแฮช SHA1 หรือทำ command-line parser มีอยู่จำกัด ดังนั้นมันอาจออกมาคล้ายกันมากก็ได้
ในคดี Oracle v. Google นี่ก็เป็นหนึ่งในประเด็นแกนกลางเช่นกัน Google โต้แย้งสำเร็จว่าการเขียนลูปมีวิธีที่จำกัด ดังนั้นการมีลูปที่คล้ายต้นฉบับจึงไม่ได้แปลว่าเป็นการละเมิดลิขสิทธิ์โดยอัตโนมัติ
ไม่ว่าอย่างไร การเลือกยืนอยู่บนจุดยืนแบบนี้ก็ดูฝืนเกินไปจริง ๆ
ไม่เข้าใจ มี Gitoxide อยู่แล้วและมันก็ยอดเยี่ยมมาก
อาจจะยังมีส่วนที่ขาดอยู่บ้าง แต่การเพิ่มความสามารถด้านเครือข่ายที่ Gitoxide ซึ่งมีการดูแลต่อเนื่องต้องการด้วยการ vibe coding น่าจะง่ายกว่าการเผาโทเคนเพื่อพยายามโคลน Git ทั้งก้อนขึ้นมาใหม่
Git ต้องการการเสริมด้วย Rust และ Gitoxide ก็เป็นโปรเจ็กต์ที่ดำเนินมาหลายปี จึงมีแนวโน้มว่าจะดูแลรักษาได้ดีกว่าโคลนแบบด้นสดด้วย vibe ที่แค่ “บอกว่าทดสอบผ่าน”
ถ้าเป็นกรณีใช้งานที่มีประโยชน์จริงก็ไม่ได้คัดค้านตัว vibe clone เอง แต่รอบนี้มองไม่เห็นข้อดี Git เป็นเครื่องมือที่หลายคนชอบ ไม่ใช่กรณีแบบ vinext ที่เกิดจากการไม่ชอบ vendor lock-in ของ Next.js
ฝั่งผู้บริหารเองก็ควรรู้ด้วยว่าเรื่องทำนอง “เราเผาเงินหลายพันดอลลาร์กับโทเคนเพื่อทำซอฟต์แวร์ที่คนรักให้กลายเป็นฉบับของเราเอง” ต่อให้ไม่นับประเด็นลิขสิทธิ์และไลเซนส์ ก็ไม่ใช่เรื่องที่จะถูกชุมชนรับในแง่บวกนัก
การเห็นงานที่ชอบถูกทำซ้ำโดยไม่ได้ประโยชน์อะไรเพิ่มขึ้นมาไม่ได้ทำให้รู้สึกดี ตอนนี้เลยช่วง “การทดลองเพื่อดูว่า AI ไปได้ไกลแค่ไหน” มาแล้ว
ช่วงนี้ก็มีความพยายามที่น่าสนใจในการเติมฟีเจอร์ Git เข้าไปใน Gitoxide ผ่าน vibe loop: https://github.com/GitoxideLabs/gitoxide/pull/2538
ถึงอย่างนั้นก็ยังคิดว่าโปรเจ็กต์นี้อาจมีคุณค่าได้ถ้าทำต่ออีกหน่อย การประกาศครั้งนี้เป็นเพียงหมุดหมาย ไม่ใช่ผลิตภัณฑ์สุดท้าย ตอนกลางโครงการเราก็ยังไม่มั่นใจเลยว่ามันจะเป็นไปได้หรือไม่
เราเรียนรู้ไปมากแล้วและยังจะได้เรียนรู้อีกมาก แต่ทั้ง Gix ซึ่งเป็นไลบรารี Git แบบบางส่วนที่ทำด้วยมืออย่างประณีตและมีแนวคิดชัดเจน กับ Grit ซึ่งเป็นไลบรารี Git จาก LLM ที่ใกล้เคียงการทำครบทั้งระบบแต่ยังค่อนข้างหยาบ ก็อาจมีพื้นที่ใช้งานที่เป็นประโยชน์ทั้งคู่ ตอนนี้ยังมองว่าคุ้มค่าที่จะสำรวจและลงทุนกับทั้งสองทางเลือกต่อไป
และผมก็เป็นผู้บริหารที่เกี่ยวข้องกับเรื่องนี้ รวมถึงตลอดหลายปีที่ผ่านมาก็ทำอะไรเพื่อชุมชน Git มาไม่น้อย แนวคิดว่าผมอยากมี “ฉบับของตัวเอง” นั้นไร้สาระมาก
ผมเขียนหนังสือ Pro Git(https://git-scm.com/book/en/v2) และก่อนหน้านั้นก็ Git community book(https://schacon.github.io/gitbook/index.html) แล้วเปิดเป็นโอเพนซอร์ส สร้างเว็บไซต์ทางการของ Git(https://git-scm.com) ร่วมก่อตั้ง GitHub ที่โฮสต์โอเพนซอร์สแทบทั้งหมดของโลก และช่วยเผยแพร่กับสนับสนุนระบบนิเวศ Git มาเกือบ 20 ปี
เมื่อ 15 ปีก่อนผมก็รื้อฟื้นการพัฒนา libgit2 ขึ้นมาใหม่และออกทุนให้ ซึ่งถ้าจะอ้างว่านี่ก็เป็นผู้บริหารที่อยากมี “ฉบับของตัวเอง” ของ Git ภายใต้ไลเซนส์ที่ผ่อนปรนกว่า ก็พิลึกพอๆ กัน
น่าจะเป็นไปได้ว่าพวกเขามองว่า gitoxide ยังไม่พอกับกรณีใช้งานของตัวเอง หรือไม่ก็ต้นทุนในการขยายและปรับปรุงสูงเกินไป
เรื่องความปลอดภัยของหน่วยความจำอะไรแบบนั้นก็ดีอยู่ แต่พูดตรงๆ ว่าไม่เข้าใจว่านี่ทำมาเพื่อ กรณีใช้งาน อะไร
จะเอาไว้สาธิตการพัฒนาแบบเอเจนต์งั้นหรือ? ใช้ Git มาสิบกว่าปีแล้วไม่เคยมีปัญหาล้มเหลวเพราะ memory overflow หรืออะไรทำนองนั้นเลย ซอฟต์แวร์บางอย่างก็อยู่ในประเภท “ดีพออยู่แล้ว” และค่อนข้างมั่นใจว่า Git ก็อยู่ในกลุ่มนั้น
แม้แต่ในทีมที่มีนักพัฒนามากกว่า 20 คนและมีไบนารีอาร์ติแฟกต์จำนวนมาก ก็แทบไม่เคยชนขีดจำกัดของ Git ถ้าคุณอยู่ในสถานการณ์ที่ดันขีดจำกัดของ Git จริงๆ ก็อาจต้องออกจาก Git ไปเลย และการเขียนใหม่ด้วย Rust ก็ไม่ได้ช่วยอะไร เพราะงั้นเลยอยากถามอีกครั้งว่า ทำไม?
ต่อให้จะทำงานเล็กๆ ก็ต้อง fork/exec โปรเซสแล้วคุยกันผ่าน stdin/stdout ไม่อย่างนั้นก็ต้องรีอิมพลีเมนต์ใหม่ทั้งหมดและจัดการทุกกรณีขอบ
ตัวอย่างเช่น การอ่านอ็อบเจ็กต์สักตัว ถ้าเป็น loose object ก็ง่าย แต่ถ้าอยู่ใน packfile จะยากขึ้นมาก การอ่าน reference เช่นตรวจว่าบรานช์ชี้ไปที่ SHA ไหน ก็อาจอยู่ใน loose file, packfile หรือ reftable ก็ได้
ไม่มีใครจะใช้สิ่งนี้เพื่อวัตถุประสงค์แบบ CLI หรอก ต่อให้ทำให้เสถียรแล้วก็ตาม ก็น่าจะแทบแน่นอนว่าช้ากว่าและแย่กว่าในทุกด้าน ตอนนี้มันก็ยังไม่เสถียรด้วย
คุณใช้ libgit2 หรือ Gitoxide ก็ได้ ซึ่งทั้งคู่ก็เป็นโปรเจ็กต์ที่ผมเคยช่วยเริ่มต้น หรือ GitButler กำลังช่วยผลักดันอยู่ในตอนนี้ เร็วกว่าและดีกว่าแทบทุกด้าน แต่ฟีเจอร์ยังไม่ครบถ้วน
นี่ไม่ได้ทำมาเพื่อคนที่ใช้ Git แต่ทำมาเพื่อคนที่จะสร้างเครื่องมือที่ต้องการใช้บางส่วนของ Git
ตอนนี้ดูเหมือนว่า ไลเซนส์ซอฟต์แวร์ จะไม่มีความหมายอีกต่อไปแล้ว เพราะใครๆ ก็แค่ตัดสินเองได้ว่า LLM clone ของตัวเองไม่ใช่งานดัดแปลง
ไม่นานมานี้ Casey Muratori ก็พูดในบริบทคล้ายกันว่าแรงผลักดันด้าน AI ของ Microsoft อาจเกี่ยวข้องกับการที่พวกเขามีโค้ดเบสขนาดใหญ่และเก่าแก่อยู่มาก บริษัทซอฟต์แวร์ขนาดใหญ่ที่มีของสะสมเก่าๆ แบบนี้มีข้อได้เปรียบในการฝึกโมเดล และสามารถเพิ่มมูลค่าจากทรัพย์สินทางปัญญาของตัวเองได้
แต่ตอนนี้ทรัพย์สินทางปัญญานั้นอาจเข้าไปอยู่ในโมเดลและเปิดให้ใครก็เข้าถึงได้ จริงๆ แล้วถ้าฝึกโมเดลด้วยทรัพย์สินทางปัญญาของตัวเอง ใครก็ตามก็อาจอิมพลีเมนต์ API นั้นแล้วติด ไลเซนส์ GPL ให้ได้
พอถึงจุดนั้นคงจะน่าสนใจจริงๆ
นี่คือการ ลอกผลงาน จากโค้ด GPL และเป็นการฟอกใบอนุญาต
การไล่ทำย้อนจาก test suite ยังพอเข้าใจได้ แต่กรณีนี้คืออ่านซอร์สต้นฉบับตรง ๆ เลย: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
คนใช้ LLM ดูเหมือนจะอยู่กันคนละโลก ที่คิดว่าสิ่งไหนก็ตามที่ไม่ได้ถูกตรึงไว้แน่นหนาก็ขโมยได้หมด แล้วเอามาอ้างว่าเป็นงานของตัวเองได้
ตัวอย่างเช่น ตอนที่ฉันพยายามทำให้การลงลายเซ็นคอมมิตผ่าน SSH ใน GitButler ใช้งานได้ถูกต้อง ฉันก็ทำแบบนั้นเป๊ะ: https://blog.gitbutler.com/signing-commits-in-git-explained
อย่างที่เห็นในบทความ ฉันขุดซอร์ส C เพื่อหาว่าพฤติกรรมที่ถูกต้องตามแบบควรเป็นอย่างไร แล้วค่อย implement สิ่งเดียวกันใน Rust โดยไม่ได้คัดลอกซอร์สโค้ดมา
มีความคล้ายกันอยู่บ้างระหว่างซอร์ส Rust ของ Grit กับซอร์สของ Git แต่ส่วนใหญ่เป็นเรื่องอย่างการจัดการเวลา การจัดรูปแบบ หรือค่า byte offset ที่จำเป็นสำหรับการ parse packfile ตามที่ฉันเห็น ไม่มีการคัดลอกโค้ดโดยตรง
ถ้าจะทำสิ่งนี้ให้เป็นโค้ดเบสที่ reentrant, memory-safe และเน้นการเป็นไลบรารี แนวทางมันต่างกันเกินไปจนการคัดลอกแทบไม่มีประโยชน์
แต่ฟอร์แมตไบนารีของ packfile หรือ reftable นั้นไม่ได้มีเอกสารที่ดีพอ จะให้เดาเอาเองก็คงเป็นไปไม่ได้ ฉันรู้เรื่องนี้ดีเพราะน่าจะเป็นหนึ่งในไม่กี่คนที่เคยพยายามเขียนเอกสารฟอร์แมตไบนารีของ packfile: https://schacon.github.io/gitbook/7_the_packfile.html
มันเลยหลีกเลี่ยงไม่ได้ที่จะต้องอ่านซอร์ส ถ้าใช้คำนิยามนี้ libgit2, Gitoxide และการเขียน Git ใหม่ทั้งหมดอื่น ๆ ก็จะกลายเป็น “การฟอกใบอนุญาต” ไปหมด เพราะต่างก็ต้องอ้างอิงซอร์สของ Git เพื่อเช็กสเปกทางเทคนิค
ถ้าคุณหาโค้ดใน Grit ที่ชัดเจนว่าคัดลอกมาแบบบรรทัดต่อบรรทัดได้ ก็บอกฉันมา ฉันจะเปลี่ยนให้ แต่ซอร์สของ Git ก็คือสเปกของ Git และไม่ว่าจะมี LLM หรือไม่ การเขียนใหม่ทุกตัวก็ถูกบังคับให้ใช้แนวทางนี้ถ้าต้องการให้เข้ากันได้
ฉันไม่เข้าใจเลยว่าผู้ถือครองทรัพย์สินทางปัญญารายอื่น ๆ เช่นคนที่มีซอฟต์แวร์ปิดมูลค่าสูง หรือเพลง หนัง หรือแม้แต่ตัว LLM เอง ถึงไม่คิดว่าต่อไป เสือดาวจะมากินหน้าพวกเขาเป็นรายต่อไป
การกัดกร่อนของทรัพย์สินทางปัญญาแบบนี้ต้องหยุด ไม่อย่างนั้นใครก็ตามที่ทำงานใช้แรงงานทางปัญญาจะพังหมด ถ้ามันกระทบแค่คนสาย FOSS ฉันก็คงกลัวว่าจะถูกโยนทิ้งไปพร้อมน้ำในอ่าง แต่เรื่องนี้ชัดเจนว่าเป็นปัญหาที่กระทบในวงกว้าง
เคยใช้อุปมาแบบ “มันเหมือนการขอพรจากจินนี่ คุณต้องกำหนดกฎพื้นฐานให้ชัดมากจริง ๆ” มาก่อน
แต่ก่อนมันให้ความรู้สึกใกล้กับโกเล็มมากกว่า ทว่าเพราะโหมดก่อกวนของ Fable https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html ตอนนี้มันดูเป็น จินนี่ ชัดเจนกว่าเดิม
เมื่อก่อนฉันจะพูดว่า “โมเดลไม่ได้ให้สิ่งที่คุณต้องการ แต่มันให้สิ่งที่คุณร้องขอ” ตอนนี้ใน Fable มันไม่แม้แต่จะให้สิ่งที่ร้องขอด้วยซ้ำ เลยไม่รู้จะว่าอย่างไร
ถ้าเป็นการทดลอง จริง ๆ แล้วฉันกลับอยากเห็นไปอีกทางหนึ่ง โปรเจกต์พวกนี้ส่วนใหญ่มักดูเหมือนเขียนใหม่เพื่อ “ประสิทธิภาพ” และคงเพราะ AI ทำให้ต้นทุนลดลง
ฉันอยากเห็นงานประหลาดแต่สนุกอย่างพอร์ต Quake III ไปเป็น Python หรือ Kubernetes เป็น Perl หรือแม้แต่ Rails เป็น Python
ถ้าจำไม่ผิด Natural Selection 2 ส่วนใหญ่ก็เขียนด้วย Lua และนั่นก็เกินสิบปีมาแล้วด้วย
มันช้ากว่า ทดสอบน้อยกว่า และเหมือนสร้าง Git implementation ที่ไม่สมบูรณ์ขึ้นมาด้วยเงินแค่ 10,000~15,000 ดอลลาร์
แถมยังเสียเวลาคนไปไม่น้อยในกระบวนการ
ก่อนหน้านี้ก็มีคนพูดอยู่ว่ามีกลุ่มอื่นทำ Rust port อยู่แล้ว ถ้าเอาเงินกับทรัพยากรพัฒนาซอฟต์แวร์ระดับนี้ไปลงตรงนั้น จะทำอะไรได้อีกตั้งมากแค่ไหน?
ดูเหมือนเราจะพิสูจน์กันไปแล้วว่า AI สามารถพอร์ตอะไรบางอย่างได้ ถ้าไม่ได้ทดสอบอย่างละเอียดพอ ตอนนี้ฉันเริ่มเห็นคุณค่าของงานแนวนี้น้อยลงเรื่อย ๆ สำหรับผู้เขียนมันอาจสนุก แต่ไม่รู้ว่ามันช่วยคนอื่นอย่างไร
ขบวนการ RiiR ทั้งหมด ดูชัดเจนมากว่าเป็นความพยายามจะหนีออกจาก GPL ซึ่งเป็นใบอนุญาตที่เอื้อประโยชน์ต่อผู้ใช้
เห็นด้วยกับครึ่งแรกของประโยคที่ว่า “เป็นการทดลองที่ค่อนข้างน่าสนใจ และคิดว่าน่าจะขัดเกลาให้กลายเป็นสิ่งที่มีประโยชน์ต่อชุมชนโดยรวมได้จริง” การทดลองเป็นสิ่งที่ทุกคนร่วมสนุกได้
แต่ตรงที่ว่า “เพราะมันไม่ได้เป็นไลบรารีที่ลิงก์ได้และ reentrant ได้ แต่ตั้งอยู่บนปรัชญา Unix ที่นำคำสั่งที่เรียบง่ายกว่ามาต่อกัน จึงนำไปใช้ในโปรเซสที่รันยาวโดยไม่มี overhead จาก fork/exec ในทุกครั้งได้ยาก” ตรงนี้มีความเห็นต่างเชิงปรัชญา
ตลอดทั้งบทความ นี่เป็นช่วงเดียวที่อธิบายว่า “ทำไม” และ แนวทางแบบ Unix เองก็อาจถือเป็นฟีเจอร์ และตอนนี้อาจยิ่งสำคัญกว่าเดิมด้วยซ้ำ: https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic
ใจความสำคัญคือทั้งประโยคที่ว่า “เพราะมันไม่ได้เป็นไลบรารีที่ลิงก์ได้และ reentrant ได้ แต่ตั้งอยู่บนปรัชญา ‘Unix’ ที่นำคำสั่งที่เรียบง่ายกว่ามาต่อกัน จึงนำไปใช้ในโปรเซสที่รันยาวสำหรับทุกงานโดยไม่มี overhead จาก fork/exec ได้ยาก”
ใช้ Git มานานกว่า 15 ปีแล้ว และไม่เคยเจอแครชแม้แต่ครั้งเดียว สรุปว่ากำลังแก้ปัญหาอะไรกันแน่?
ถึงอย่างนั้น เสถียรภาพโดยรวมก็ยอดเยี่ยมมากจริง ๆ เพียงแต่ตอบไม่ได้ว่า “ทำไม?” ของการเขียนใหม่นี้คืออะไร
คนพวกนี้ลงมือทำอะไรแบบไร้เดียงสาโดยไม่รู้ตัว และสูญเสียความสามารถในการคิดด้วยตัวเองไปแล้ว ส่วน LLM ที่คิดแทนก็ไม่ได้บอกว่า “การทำ X เป็นความคิดที่ไม่ดี” LLM มีไว้เพื่อผลิตโทเค็นให้ได้มากที่สุดเท่าที่จะทำได้เพื่อเจ้าของมัน
เรื่องนี้มาจากผู้ร่วมก่อตั้ง GitHub ซึ่งน่าจะเป็นคนที่รู้ดีมากว่า GPL มีไว้เพื่ออะไร
ไม่ว่าข้อดีข้อเสียทางกฎหมายจะเป็นอย่างไร การนำทั้งชุดทดสอบของโปรเจกต์ GPL3 มาสร้างต่อแล้วรีไลเซนส์เป็น MIT ไม่ใช่การ ปฏิบัติด้วยเจตนาดี ต่อผู้เขียนต้นฉบับ
น่าขยะแขยงจริง ๆ และทำให้อยากหลีกเลี่ยง GitButler ทั้งหมด
เลือกไลเซนส์นั้นเองแล้วจะมาทีหลังเพื่อเพิ่มเงื่อนไขเพิ่มเติมเพราะไม่ชอบใจก็ไม่ได้ นั่นเป็นสิ่งที่ไลเซนส์ GPL ไม่ได้อนุญาตไว้อย่างชัดเจน