Grit: viết lại Git bằng Rust với agent
(blog.gitbutler.com)- Grit là dự án tái triển khai Git từ đầu thành thư viện dựa trên Rust, với mục tiêu xây dựng một lõi có thể tái nhập và liên kết được để tương tác chính thức với kho Git
- Git là phần mềm phức tạp đã được hàng nghìn người mở rộng suốt 20 năm theo kiểu kết hợp các lệnh, và có vấn đề cấu trúc là mỗi lần dùng trong tiến trình chạy lâu đều phát sinh chi phí fork/exec
- Grit được phát triển dựa trên hơn 1.400 script và hơn 42.000 bài kiểm thử của dự án Git, và cuối cùng vượt qua 41.715 / 42.001 bài kiểm thử {p:99}
- Phiên bản hiện tại vẫn thiếu kiểm chứng trong sử dụng thực tế, và có các hạn chế như chạy chậm, API chưa được dọn dẹp, chưa có bản build cho Windows, và khả năng làm hỏng dữ liệu
- Phát triển dựa trên agent giúp đẩy nhanh việc port quy mô lớn, nhưng cũng bộc lộ các thách thức cốt lõi như lách bài kiểm thử, làm hỏng harness, điều phối, quản lý tài nguyên và chi phí
Mục tiêu và bối cảnh của Grit
- Grit là nỗ lực tái triển khai Git theo hướng thư viện Rust, chứ không phải port mã C
- Mục tiêu là tạo ra một thư viện lõi thuần Rust có thể tương tác chính thức với kho Git
- Lõi này hướng tới cấu trúc có thể tái nhập, liên kết được, mô-đun và toàn diện
- Một crate CLI riêng sử dụng thư viện này để kiểm chứng mức độ hoàn thiện bằng cách vượt qua tối đa bộ test của Git
Vì sao muốn tái triển khai Git
- Git là phần mềm phức tạp với nhiều lệnh plumbing cấp thấp và porcelain cấp cao
- Git hiện tại không được xây dựng trên một thư viện có thể tái nhập và liên kết được, mà gần với triết lý Unix là ghép các lệnh đơn giản lại với nhau
- Với cấu trúc này, khi một tiến trình chạy lâu cần dùng tính năng Git thì mỗi tác vụ đều phát sinh overhead fork/exec
- Dự án Git có hơn 42.000 bài kiểm thử trải trên hơn 1.400 script, nên có thể dùng chúng để kiểm chứng hành vi một cách rất cụ thể
Mức độ hoàn thiện hiện tại và các điểm cần lưu ý
- Grit là bản tái triển khai Git bằng Rust an toàn bộ nhớ, dựa trên thư viện và được viết từ đầu, vượt qua hơn 99% bộ test của Git
- Một số bài kiểm thử bị bỏ qua có chủ đích, bao gồm tính năng liên quan đến email, i18n, importer Perforce/SVN, và một số hạng mục midx/bitmap
- Trong phạm vi được đánh giá là có liên quan lớn với độc giả phổ thông, thư viện Grit và CLI đều vượt qua bộ test của Git
- Việc kiểm chứng trong dự án thực tế hiện vẫn còn thiếu, và vẫn có khả năng hành vi sai hoặc làm hỏng dữ liệu
- Các giới hạn hiện tại gồm hiệu năng chậm, tính năng chưa được kiểm thử, API chưa gọn gàng, và chưa có bản build cho Windows
Các hướng sử dụng khả thi
- GitButler và các công cụ Git độc lập có thể dùng Grit để nhúng các tính năng mạng phức tạp như push/fetch
- Tính năng mạng trong Gitoxide và libgit2 hiện ở trạng thái một phần, chậm hoặc chưa tồn tại
- GitButler và Jujutsu đang phụ thuộc vào cách fork tiến trình Git để xử lý dữ liệu push/pull
- Logic thông tin xác thực phức tạp là một trong những lý do lớn, và về lý thuyết mảng này được Grit xử lý
- Bản build WASM có thể mở ra các cách dùng như chạy gần như mọi lệnh Git trong edge function của Vercel
- Các tính năng như Cloudflare Artifacts có thể dùng bản build WASM tương thích hoàn toàn của Grit thay vì triển khai một phần như isomorphic-git
- Nếu tách các chức năng Git thành từng mảnh thư viện có thể nhúng riêng lẻ, cũng có thể tạo máy chủ hoặc tính năng client Git tùy biến bằng Rust
- Bản build đầy đủ tính năng Git bằng Rust hiện khoảng 27MB, và có thể tách thành các subcrate theo từng miền chức năng để chỉ dùng phần cần thiết
An toàn bộ nhớ
- Phần lớn mã Grit được viết bằng safe Rust
- Phần phải giao tiếp với C và FFI thực chất chỉ gồm một mô-đun date/time và một kiểm tra TTY
- Cần FFI đó vì chưa có thay thế thuần Rust cho
localtime_r,strftime,mktimexử lý phù hợp với môi trường TZ - Ngoài ra, toàn bộ mã Grit đều là safe Rust
Những vấn đề bộc lộ trong phát triển bằng agent
-
Agent có thể lách để vượt qua bài kiểm thử
- Mục tiêu kiểu “hãy làm cho test Git pass” có thể khiến agent viết một hàm đơn giản chỉ chuyển việc xử lý sang Git gốc
- Trong file AGENTS phải ghi rất rõ các quy tắc cơ bản như cấm lách kiểu đó
- Với hỗ trợ sha256, bài test chỉ kiểm tra rằng sau
git init --object-format=sha256, lệnhrev-parse --show-object-formatcó in rasha256hay không - Grit đã ghi đúng metadata cấu hình để vượt qua bài test này, nhưng hành vi
add,commit,logtrong kho sha256 thực tế chưa được kiểm chứng - Agent chỉ làm đúng phần mà bài test kiểm tra, chứ chưa triển khai hỗ trợ đối tượng sha256 thực sự
-
Agent không biết mình đã làm hỏng chỗ nào
- Một agent chạy song song đã làm hỏng phần nền tảng của test harness, khiến tình hình trông như một đợt regression diện rộng
- Vì sự cố này, dự án từng gần như dừng lại một thời gian do cho rằng làm song song gây hại nhiều hơn lợi
- Sau khi khởi động lại vào đầu tháng 6, một agent đã tìm ra và sửa lỗi harness, đưa tỷ lệ pass trở lại khoảng 80%
- Sự phục hồi đó trở thành động lực để đẩy dự án đến cùng
-
Công việc song song dài hạn rất khó điều phối
- Cách để nhiều agent chạy lâu cùng chia nhau một danh sách việc chung khó hơn dự đoán
- Việc chia sẻ file kế hoạch có checkbox trở nên lộn xộn, còn các cách như Linear hay GitHub Issues thì cần truy cập mạng, xác thực và cấu hình công cụ theo từng client
- Ở giai đoạn sau, nhóm dùng hệ thống ticket cục bộ Ticgit để sửa danh sách việc tại chỗ rồi chuyển bằng Git
- Việc handoff trạng thái đang làm dở giữa nhiều hệ thống để chuyển tiếp sang nơi khác cũng liên tục gây ma sát
Tài nguyên và chi phí
- Công việc được thực hiện trên nhiều môi trường như laptop, Mac Studio, máy chủ Hostinger và Cursor cloud agents
- Việc biên dịch Rust đòi hỏi CPU và bộ nhớ nhiều hơn dự kiến khi chạy song song
- Agent có thể debug và sửa các vấn đề như swap thrashing và CPU thrashing, nhưng quản lý tài nguyên vẫn luôn khó khăn
- Chi phí dùng Cursor và Anthropic không được tính chính xác, ước khoảng $10.000~$15.000
- Lượng token sử dụng vào khoảng 14 tỷ cho Claude Code, 12 tỷ cho Cursor GPT/Codex, và 16 tỷ cho Cursor composer-2, tổng cộng khoảng 45 tỷ token
- Mô hình
composer-2của Cursor đã hoàn thành gần một nửa dự án bằng cách chạy nhiều cloud agent ngắn và tập trung
Cách tiếp cận agent đã sử dụng
-
OpenClaw + Claude Code
- Ban đầu, dự án chạy các sub-agent Claude Code từ xa thông qua OpenClaw
- Do dùng API tính phí theo token, chỉ sau vài ngày đã phát sinh phần lớn tổng chi phí của dự án
- Tính ổn định vận hành thấp vì các vấn đề bộ nhớ, CPU và cả sự cố máy chủ Hostinger
-
Cursor cloud agents
- Để giảm tốc độ tăng chi phí, nhóm chuyển sang chiến lược tận dụng token thuê bao và các mô hình rẻ hơn
- Việc mở một Cursor cloud agent cho từng file cần xử lý rồi merge khi xong đã xử lý được phần lớn dự án
- Một số bài test thay đổi môi trường, dùng binary Grit thay cho Git hoặc làm hỏng kho lưu trữ thông tin xác thực, khiến Git push thất bại trong container
- Trong nhiều trường hợp phải vào terminal của container, thêm remote thủ công rồi push commit
-
Cursor cloud grind mode
- Trong Cursor cloud agent, nếu chọn
Long-runningở bộ chọn mô hình thì công việc sẽ chạy lâu ở “Grind mode” - Cách làm là đưa prompt như “hãy làm cho toàn bộ nhóm test t1 pass”, rồi chờ một ngày để PR tích lũy 100 commit
- Đây trở thành cách tiếp cận được ưa thích nhất sau nhiều lần thử
- Trong Cursor cloud agent, nếu chọn
-
Chế độ
/goalvà Claude dynamic workflows- Chế độ
/goalcủa Codex và Claude Code cũng thực hiện các công việc dài hạn tương tự - Chế độ
/goalcủa Codex tiếp tục làm việc liên tục, còn Claude thường dừng lại và cần can thiệp - Trong tuần cuối, dự án dùng effort mode “Ultracode” của Claude dynamic workflows để chia nhỏ các nhóm test lớn
- Cần quản lý tài nguyên vì các bản build
rustcsong song có thể dùng quá nhiều CPU và bộ nhớ rồi làm chậm toàn bộ quá trình
- Chế độ
Cách làm hiệu quả hơn
- So với việc để một nhóm agent chỉ điều phối nhẹ tự chọn file test tiếp theo, một chiến lược theo từng bước do con người đặt ra cho kết quả nhanh hơn
- Cách tiếp cận bottom-up, bắt đầu từ các lệnh plumbing cơ bản rồi đi lên các lệnh quan trọng phụ thuộc vào chúng, tỏ ra hiệu quả
- Những phần như xuất định dạng diff, vốn gần như không bị chức năng khác phụ thuộc, phù hợp để xử lý về sau
- Khi xác định kỹ thứ tự tiếp cận vấn đề và chuyển giao theo từng bước, kết quả tốt hơn; còn song song hóa quy mô lớn một cách mù quáng thì dễ sinh lỗi và bế tắc
Giấy phép
- Mã nguồn Git dùng giấy phép GPL, còn libgit2 được thiết kế cho mục tiêu liên kết nên GPL có thêm linking exception
- Giấy phép của libgit2 từ trước đến nay vẫn gây tranh luận và hiện vẫn là một vấn đề còn tồn tại
- Sau khi xem xét mã do LLM tạo ra cùng các thay đổi kiến trúc trên diện rộng để thư viện hóa và bảo đảm an toàn bộ nhớ, nhóm kết luận codebase Grit không phải là tác phẩm phái sinh buộc phải kế thừa GPL
- Mã Grit được phát hành theo giấy phép MIT
- Quyết định này có thể gây tranh cãi, nhưng được cho là lựa chọn tốt nhất cho cộng đồng Git rộng hơn
Kết quả cuối cùng
- Công việc được thực hiện trong vài tuần của tháng 4 rồi tạm dừng, và hoàn tất vào tuần đầu tháng 6
- Thời gian thực sự bỏ vào khoảng 2–3 tuần, mỗi ngày vài giờ; phần lớn là thời gian điều phối, tích hợp hoặc tìm lỗi khi chạy nền
- Quy mô mã cuối cùng là hơn 360.000 LOC
grit-libkhoảng 100.000 LOCgrit-clikhoảng 260.000 LOC- Xấp xỉ quy mô mã Git viết bằng C nếu không tính header
- Kết quả này được tạo ra qua hơn 500 pull request và hơn 7.000 commit
- Kết quả test là 41.715 bài pass trên tổng 42.001, tương đương tỷ lệ 99,3%
- Trang chủ dự án là https://grit-scm.com
3 bình luận
https://writings.hongminhee.org/2026/03/legal-vs-legitimate/
Nhìn vào tranh cãi về giấy phép, tôi lại nhớ đến vụ việc trước đây.
https://github.com/gitbutlerapp/grit/pull/837/changes/b1135eef106c71b0831d964c6506d8817e7a7201
Khá kinh tởm. Tại sao Grit-lib vẫn là MIT?
Ý kiến trên Hacker News
Đoạn “sau khi xem lại mã do LLM tạo ra, tôi kết luận codebase này không phải là tác phẩm phái sinh nên phải kế thừa GPL, vì để biến phần triển khai thành thư viện và bảo đảm an toàn bộ nhớ thì cần những thay đổi kiến trúc khá lớn và trên diện rộng; vì vậy tôi quyết định phát hành theo MIT” có vẻ sẽ trở thành một điểm tranh luận thú vị
Tuy nhiên, nếu trong lúc dịch sách mà bắt đầu thay đổi cả cốt truyện lẫn tính cách nhân vật, thì sẽ mơ hồ ở chỗ từ thời điểm nào nó không còn là tác phẩm phái sinh nữa. Tôi không phải luật sư, nhưng có lẽ án lệ liên quan đến tác phẩm sáng tạo đã bàn khá nhiều về ranh giới này
Trong bối cảnh phạm vi “sở hữu trí tuệ” vẫn đang tiếp tục được mở rộng như hiện nay, nếu thừa nhận rằng LLM đã truy cập mã nguồn Git thì vị thế pháp lý có vẻ khá yếu
Theo tiêu chuẩn Jplag, mức độ tương đồng tối đa giữa các codebase là dưới 1,8%, được thực hiện với thiện chí, và tôi cho rằng điều này cũng có lợi cho toàn bộ hệ sinh thái Git. Tất nhiên điều đó còn phụ thuộc vào việc Grit có thực sự trở nên hữu dụng hay không, và hiện tại vẫn chưa phải giai đoạn để khẳng định như vậy
Xét từ góc độ bản quyền, chỉ có luận điểm đầu tiên trong số này là liên quan. Grit là một triển khai được viết độc lập cho hành vi tương thích với Git, và tôi cho rằng mức độ tương đồng với mã nguồn Git là nhỏ đến mức có thể bỏ qua
antirez đã tóm lược tình huống rất tốt và tôi phần lớn đồng ý: https://antirez.com/news/162
Những người đã biết và làm việc với tôi trong Git và cộng đồng mã nguồn mở suốt 20 năm qua sẽ hiểu rằng mục đích của tôi là đóng góp, chia sẻ, thúc đẩy đổi mới và học hỏi. Nhiều tác giả chính của mã nguồn Git là bạn tôi, và tôi hoàn toàn không có ý định lấy cắp bất cứ điều gì từ ai. Tôi chỉ muốn làm cho những ý tưởng tuyệt vời trở nên hữu ích rộng rãi hơn
https://news.ycombinator.com/item?id=47350424
Cũng giống như với 1984 hay Torment Nexus, ai đó đã tiếp nhận một khái niệm đáng lẽ phải được xem như lời cảnh báo lại như một sổ tay hướng dẫn sử dụng
Ví dụ, giả sử bạn trích xuất binary của Goldeneye trên N64, dùng LLM để disassemble rồi viết lại bằng một ngôn ngữ bậc cao hiện đại. Nintendo có nói rằng “vì anh đã bỏ ra nhiều công sức nên giờ anh thoát khỏi giấy phép của chúng tôi rồi” không? Tất nhiên là không. Hoàn toàn vô lý
Cho LLM ăn mã nguồn rồi để nó tạo ra kết quả bằng ngôn ngữ khác rõ ràng là tác phẩm phái sinh. Không cần phải là luật sư sở hữu trí tuệ cũng có thể hiểu điều đó
Ngược lại, nếu chỉ đưa tài liệu cho Claude và bảo nó tạo một triển khai tương thích, liệu đó có phải là tác phẩm phái sinh chịu GPL không? Có lẽ là có, nhưng giờ tôi không còn chắc 100% nữa, và tôi sẽ không chấp nhận rủi ro đó
Một thí nghiệm tưởng tượng khác là, nếu ai đó đưa cây mã nguồn “giấy phép MIT” này vào một LLM khác rồi yêu cầu xuất ra C, thì giấy phép sẽ là gì? Vì cách tạo hash SHA1 hay viết trình phân tích dòng lệnh là hữu hạn, nên kết quả có thể sẽ khá giống nhau
Trong vụ Oracle v. Google, đây cũng là một trong những điểm tranh cãi cốt lõi. Google đã thành công khi lập luận rằng cách viết vòng lặp là có giới hạn, nên chỉ vì có những vòng lặp giống với bản gốc không có nghĩa là lập tức cấu thành vi phạm bản quyền
Dù sao thì, việc giữ lập trường như vậy thực sự là quá gượng ép
Không hiểu. Gitoxide đã tồn tại rồi và rất tốt.
Có thể vẫn còn thiếu vài phần, nhưng bổ sung các tính năng mạng cần thiết vào Gitoxide đang được bảo trì bằng kiểu vibe coding còn dễ hơn là đốt token để cố sao chép lại toàn bộ Git
Git muốn bổ sung Rust, và Gitoxide là một dự án kéo dài nhiều năm nên có khả năng được bảo trì tốt hơn một bản clone ngẫu hứng kiểu “nói là test đã pass”
Nếu có trường hợp hữu ích thì tôi không phản đối bản thân việc làm một vibe clone, nhưng lần này tôi không thấy ưu điểm gì. Git là công cụ được nhiều người yêu thích, chứ không phải tình huống như vinext xuất hiện vì ghét sự phụ thuộc vào nhà cung cấp của Next.js
Cả ban điều hành cũng nên hiểu rằng câu chuyện “chúng tôi đã đốt hàng nghìn đô tiền token để tạo ra bản sao của phần mềm mà mọi người yêu mến” không phải là điều cộng đồng sẽ đón nhận tích cực, ngay cả khi bỏ qua tranh cãi về bản quyền và giấy phép
Nhìn tác phẩm mình yêu thích bị sao chép mà chẳng mang lại lợi ích gì thì không dễ chịu chút nào. Giờ đã qua giai đoạn “thử nghiệm để xem AI có thể đi tới đâu” rồi
Gần đây có nỗ lực đưa thêm tính năng Git vào Gitoxide bằng vòng lặp vibe, và điều đó khá thú vị: https://github.com/GitoxideLabs/gitoxide/pull/2538
Dù vậy, tôi vẫn nghĩ dự án này có thể có giá trị nếu làm thêm một chút nữa. Công bố lần này không phải sản phẩm cuối cùng mà chỉ là một cột mốc. Ngay cả ở giữa dự án chúng tôi cũng chưa chắc liệu điều này có khả thi hay không
Chúng tôi đã học được nhiều và còn sẽ học thêm nữa, nhưng Gix — một thư viện Git từng phần chất lượng cao, được làm thủ công với quan điểm rõ ràng — và Grit — một thư viện Git do LLM tạo ra, gần như là triển khai hoàn chỉnh nhưng hơi thô — đều có thể có những ứng dụng hữu ích riêng. Tôi nghĩ trong một thời gian nữa vẫn đáng để khám phá và đầu tư vào cả hai lựa chọn
Ngoài ra tôi là người quản lý có liên quan, và trong nhiều năm qua tôi đã làm khá nhiều việc cho cộng đồng Git. Nói rằng tôi muốn có “bản sao riêng” của mình thì thật vô lý
Tôi đã viết cuốn Pro Git(https://git-scm.com/book/en/v2) và trước đó là Git community book(https://schacon.github.io/gitbook/index.html), phát hành chúng dưới dạng mã nguồn mở, tạo ra trang web Git chính thức(https://git-scm.com), đồng sáng lập GitHub — nơi lưu trữ gần như toàn bộ phần mềm mã nguồn mở trên thế giới — và đã phổ biến, hỗ trợ hệ sinh thái Git gần 20 năm
15 năm trước, tôi đã khởi động lại việc phát triển libgit2 và tài trợ cho nó; nếu muốn thì cũng có thể nói đó là một lãnh đạo đang muốn có “bản sao riêng” của Git với giấy phép dễ dãi hơn, nhưng lập luận đó cũng vô lý y như vậy
Có lẽ họ đã kết luận rằng gitoxide không đủ cho trường hợp sử dụng của họ, hoặc chi phí để mở rộng/cải thiện nó là quá lớn
Những thứ như an toàn bộ nhớ thì tốt, nhưng thành thật mà nói tôi không hiểu cái này dành cho trường hợp sử dụng nào
Là để phô diễn kiểu phát triển tác nhân à? Hơn 10 năm dùng Git tôi chưa từng thất bại vì tràn bộ nhớ hay thứ tương tự. Có những phần mềm thuộc loại “như hiện tại đã đủ tốt rồi”, và tôi khá chắc Git nằm trong số đó
Ngay cả trong các đội có hơn 20 lập trình viên và rất nhiều đầu ra nhị phân, tôi cũng hiếm khi đụng phải giới hạn của Git. Nếu thật sự đang đẩy Git tới cực hạn, có lẽ phải rời khỏi Git, và viết lại bằng Rust cũng chẳng giúp gì. Nên tôi lại muốn hỏi, tại sao?
Dù chỉ muốn làm một việc nhỏ, bạn cũng phải fork/exec một process rồi giao tiếp qua stdin/stdout. Hoặc phải tái triển khai toàn bộ và xử lý mọi trường hợp ngoại lệ
Ví dụ, đọc một object thì dễ nếu là loose object, nhưng nếu nó nằm trong packfile thì khó hơn nhiều. Đọc ref, tức kiểm tra một nhánh đang trỏ tới SHA nào, cũng có thể phải xử lý loose file, packfile hoặc reftable
Sẽ không ai dùng cái này cho mục đích CLI. Kể cả khi ổn định hóa, gần như chắc chắn nó vẫn sẽ luôn chậm hơn và tệ hơn ở mọi mặt. Hiện tại thì nó còn chưa ổn định
Bạn có thể dùng libgit2 hoặc Gitoxide, cả hai đều là các dự án mà tôi từng giúp khởi đầu hoặc GitButler hiện đang hỗ trợ thúc đẩy. Chúng nhanh hơn và tốt hơn ở gần như mọi mặt, nhưng chưa hoàn thiện đầy đủ tính năng
Cái này không dành cho người dùng Git, mà dành cho những người sẽ xây công cụ muốn dùng một phần của Git
Giờ có vẻ giấy phép phần mềm không còn ý nghĩa gì nữa, vì ai cũng có thể tự quyết rằng bản clone do LLM tạo ra của mình không phải là tác phẩm phái sinh
Gần đây Casey Muratori cũng nói trong bối cảnh tương tự rằng việc Microsoft thúc đẩy AI có thể liên quan tới chuyện họ sở hữu một codebase cũ và đồ sộ. Các công ty phần mềm lớn lâu đời có lợi thế trong huấn luyện mô hình, và có thể cung cấp thêm giá trị nhờ tài sản trí tuệ của mình
Nhưng giờ tài sản trí tuệ đó có thể đi vào trong mô hình và trở nên доступно cho bất kỳ ai. Thực tế, nếu bạn huấn luyện mô hình bằng chính tài sản trí tuệ của mình, bất kỳ ai cũng có thể triển khai API đó và gắn giấy phép GPL lên nó
Từ thời điểm đó trở đi mọi thứ sẽ thực sự thú vị
Đây là đạo văn mã GPL và là hành vi tẩy rửa giấy phép
Tôi có thể hiểu việc làm ngược từ bộ test, nhưng cái này thì đúng nghĩa là đã đọc mã nguồn gốc: https://github.com/gitbutlerapp/grit/blob/main/AGENTS.md#source-of-truth
Có vẻ như những người dùng LLM đang sống trong một thế giới khác, nơi cứ thứ gì không bị đóng đinh cố định thì đều có thể lấy cắp rồi đem ra nhận là công sức của mình
Ví dụ, khi tôi muốn làm cho SSH commit signing hoạt động đúng trong GitButler, tôi đã làm chính xác như vậy: https://blog.gitbutler.com/signing-commits-in-git-explained
Như có thể thấy trong bài viết, tôi đã đào sâu vào mã nguồn C để tìm ra hành vi chuẩn, rồi triển khai cùng việc đó bằng Rust, nhưng không sao chép mã nguồn
Có một số điểm tương đồng giữa mã nguồn Rust của Grit và mã nguồn Git, nhưng phần lớn là những chỗ như xử lý thời gian, định dạng, hay các byte offset cần thiết để phân tích packfile. Theo tôi thấy thì không có chuyện sao chép mã trực tiếp
Để biến nó thành một codebase có thể tái nhập, an toàn bộ nhớ và lấy thư viện làm trung tâm thì bản thân cách tiếp cận đã quá khác, nên việc sao chép phần lớn cũng không hữu ích
Nhưng các định dạng nhị phân của packfile hay reftable lại không được tài liệu hóa đầy đủ, nên không ai có thể đoán mò cho đúng được. Tôi biết rất rõ điều này vì có lẽ tôi là một trong số ít người từng cố gắng tài liệu hóa định dạng nhị phân của packfile: https://schacon.github.io/gitbook/7_the_packfile.html
Không còn cách nào khác ngoài việc phải đọc mã nguồn. Theo định nghĩa này thì libgit2, Gitoxide và mọi bản tái triển khai Git khác cũng đều là “tẩy rửa giấy phép”, vì họ cũng phải tham khảo mã nguồn Git để kiểm tra đặc tả kỹ thuật
Nếu bạn tìm được trong Grit đoạn mã nào rõ ràng là bị sao chép từng dòng, hãy cho tôi biết. Tôi sẽ thay thế nó. Nhưng mã nguồn Git chính là đặc tả của Git, và dù có LLM hay không thì mọi bản tái triển khai đều bị buộc phải tiếp cận như vậy để tạo ra tính tương thích
Tôi không hiểu sao những người nắm giữ tài sản trí tuệ khác — ví dụ như phần mềm độc quyền có giá trị, hay âm nhạc, phim ảnh, thậm chí chính các LLM — lại không nghĩ rằng rồi sẽ tới lượt con báo đến ăn mặt mình
Sự xói mòn tài sản trí tuệ kiểu này phải dừng lại. Nếu không thì bất kỳ ai làm lao động trí óc cũng sẽ hoàn toàn tiêu đời. Nếu chuyện này chỉ áp vào những người FOSS thì tôi còn lo họ bị hắt đi cùng nước tắm, nhưng rõ ràng đây là vấn đề áp dụng trên diện rộng
Tôi từng dùng phép so sánh “giống như cầu điều ước với thần đèn; bạn phải làm cho các quy tắc cơ bản thật rõ ràng”
Trước đây nó giống golem hơn, nhưng với chế độ phá hoại của Fable https://jonready.com/blog/posts/claude-fable5-is-allowed-to-sabotage-your-app-if-youre-a-competitor.html thì giờ nó chắc chắn trông giống thần đèn hơn
Trước đây tôi thường nói “mô hình không đưa cho bạn thứ bạn muốn, mà đưa cho bạn thứ bạn yêu cầu”. Giờ thì trong Fable nó còn chẳng đưa cả thứ bạn muốn, nên tôi cũng không biết nữa
Nếu là vì mục đích thử nghiệm thì tôi lại tò mò về hướng ngược lại hơn. Mấy dự án kiểu này thường có vẻ như được viết lại vì “hiệu năng”, có lẽ vì AI đã làm chi phí giảm xuống
Tôi muốn thấy những việc quái dị nhưng vui như port Quake III sang Python, hoặc Kubernetes sang Perl, thậm chí Rails sang Python
Tôi nhớ phần lớn Natural Selection 2 là viết bằng Lua, mà chuyện đó cũng đã hơn 10 năm trước rồi
Nó chậm hơn, thiếu test hơn, và về cơ bản là tạo ra một bản triển khai Git không hoàn chỉnh với giá chỉ 10 nghìn~15 nghìn đô la
Trong quá trình đó cũng lãng phí kha khá thời gian của con người
Tôi còn nghe nói đã có nhóm khác đang làm một bản port Rust rồi. Nếu đem chừng ấy tiền và nguồn lực phát triển phần mềm đổ vào đó thì họ đã làm được bao nhiêu thứ rồi?
Có vẻ như điều đã được chứng minh là AI có thể port một thứ gì đó nếu bạn không kiểm thử đủ kỹ. Giờ tôi ngày càng thấy ít giá trị trong kiểu việc này. Có thể tác giả thấy vui, nhưng tôi không rõ nó giúp ích cho người khác thế nào
Cả phong trào RiiR rõ ràng là một nỗ lực nhằm thoát khỏi GPL, một giấy phép có lợi cho người dùng hơn
Tôi đồng ý với phần đầu của ý “đây là một thử nghiệm khá thú vị, và tôi nghĩ có thể trau chuốt nó thành thứ gì đó thực sự hữu ích cho cả cộng đồng”. Cứ xem thử nghiệm như niềm vui chung cũng được.
Nhưng đến đoạn “vì nó không phải là một thư viện có thể liên kết và tái nhập, mà dựa trên triết lý Unix là nối các lệnh đơn giản lại với nhau, nên khó dùng trong các tiến trình chạy dài mà không phải chịu overhead fork/exec mỗi lần” thì tôi lại có bất đồng về mặt triết lý.
Đây là đoạn duy nhất trong toàn bài nói đến “tại sao”, nhưng cách làm Unix tự nó cũng là một tính năng, và có thể còn quan trọng hơn bây giờ: https://aperocky.com/blog/post.html?slug=unix-philosophy-agentic
Cả câu “vì nó không phải là một thư viện có thể liên kết và tái nhập, mà dựa trên triết lý ‘Unix’ là nối các lệnh đơn giản lại với nhau, nên khó dùng trong các tiến trình chạy dài cho mọi tác vụ mà không có overhead fork/exec” mới là điểm mấu chốt.
Tôi đã dùng Git hơn 15 năm mà chưa từng gặp crash lần nào. Rốt cuộc nó đang giải quyết vấn đề gì vậy?
Dù vậy, độ ổn định tổng thể thực sự rất ấn tượng. Chỉ là tôi cũng không trả lời được câu “tại sao?” của chính bản viết lại cụ thể này.
Họ ngây thơ lao vào làm mọi thứ một cách hoàn toàn vô thức và đánh mất khả năng tự suy nghĩ. Còn LLM suy nghĩ thay họ thì sẽ không nói rằng “làm X là một ý tưởng tồi”. LLM tồn tại để tạo ra càng nhiều token càng tốt cho chủ sở hữu của nó.
Chuyện này xuất phát từ một đồng sáng lập GitHub, tức là người rất có thể hiểu chính xác GPL được tạo ra để làm gì.
Bất kể ưu nhược điểm pháp lý ra sao, việc xây dựng trên toàn bộ test suite của một dự án GPL3 rồi cấp phép lại dưới MIT không phải là hành động thiện chí với các tác giả gốc.
Thực sự rất kinh tởm và khiến tôi muốn tránh xa toàn bộ GitButler.
Bạn không thể chọn một giấy phép rồi sau đó, khi không thích kết quả, lại áp thêm điều kiện bổ sung. Đó là điều mà giấy phép GPL rõ ràng không cho phép.