Tin tức kỹ thuật liên quan đến GitUI

 (github.com/extrawurst)
10 điểm bởi GN⁺ 2024-01-08 | 1 bình luận | Chia sẻ qua WhatsApp
  • GitUI là công cụ mang lại tính tiện dụng và sự thuận tiện của Git GUI ngay trong terminal, bắt nguồn từ các trường hợp người dùng gặp vấn đề khi Git GUI hiện có bị treo hoặc chậm đi trong những repository khổng lồ
  • Các chức năng chính bao gồm thao tác chỉ bằng bàn phím, trợ giúp theo ngữ cảnh, kiểm tra thay đổi·commit·amend, stage/unstage/revert/reset theo đơn vị file·hunk·line, stash, push/fetch, quản lý branch, tìm kiếm log commit và xem diff
  • Trong phép so sánh parse hơn 900.000 commit của repository Git Linux, gitui ghi nhận 24 giây, bộ nhớ 0,17GB, trong khi lazygit ghi nhận 57 giây·2,6GB và tig ghi nhận 4 phút 20 giây·1,3GB
  • Các mục tiêu trước bản 1.0 gồm trực quan hóa cấu trúc branch trong tab log và interactive rebase; có các giới hạn đã biết với git-lfs, sparse repo và xử lý tự động credential.helper cho HTTPS
  • Hiện tại, công cụ này chưa thay thế hoàn toàn Git shell, mà gần với một công cụ dùng kèm để bổ trợ các tác vụ bất tiện trong Git shell như stash hoặc staging theo line·hunk

Công cụ đưa trải nghiệm Git GUI vào terminal

  • GitUI là công cụ mã nguồn mở cung cấp trải nghiệm người dùng và sự tiện lợi của Git GUI trong terminal
  • Động lực phát triển xuất phát từ trải nghiệm dù thực hiện phần lớn tác vụ Git trong terminal, người dùng vẫn thường xuyên dùng Git GUI cho các tác vụ như index, commit, diff, stash, blame, log
  • Các Git GUI phổ biến hiện có gặp vấn đề thất bại, mất phản hồi hoặc không thể sử dụng được với những repository khổng lồ
  • GitUI đặt mục tiêu mang lại trải nghiệm Git GUI portable, fast, free, opensource ngay trong terminal

Phạm vi tính năng

  • Mô hình thao tác xoay quanh điều khiển chỉ bằng bàn phím và trợ giúp theo ngữ cảnh, được thiết kế để không cần ghi nhớ nhiều phím tắt
  • Các tác vụ với thay đổi bao gồm:
    • inspect, commit, amend thay đổi
    • Bao gồm các hook pre-commit, commit-msg, post-commit, prepare-commit-msg
    • stage, unstage, revert, reset theo đơn vị file, hunk, line
  • Cũng hỗ trợ các tác vụ luồng repository:
    • lưu stash, pop, apply, drop, inspect
    • push lên remote, fetch từ remote
    • tạo, đổi tên, xóa, checkout branch, xem remotes
    • duyệt log commit và tìm kiếm, xem diff của các thay đổi đã commit
  • UI và hoạt động bên trong bao gồm UI terminal phản hồi nhanh, Git API bất đồng bộ để thao tác mượt mà, và hỗ trợ submodule
  • Hỗ trợ GPG commit signing nhưng có hạn chế liên quan đến #97

Kết quả benchmark

  • Trong bài trình bày tại RustBerlin meetup, lazygit, tig, gitui được so sánh bằng cách parse toàn bộ repository Git Linux
  • Kết quả so sánh như sau:
    • gitui: 24 giây, bộ nhớ 0,17GB, binary 10MB, không freeze, không crash
    • lazygit: 57 giây, bộ nhớ 2,6GB, binary 25MB, có freeze, thỉnh thoảng crash
    • tig: 4 phút 20 giây, bộ nhớ 1,3GB, binary 0,6MB, thỉnh thoảng freeze, không crash
  • Trong phép so sánh này, gitui ghi nhận giá trị thấp nhất ở các hạng mục thời gian và bộ nhớ

Roadmap trước 1.0 và các giới hạn đã biết

  • Có hai mục tiêu cấp cao trước khi gọi là bản 1.0:
    • Trực quan hóa cấu trúc branch trong tab log: #81
    • interactive rebase: #32
  • Các giới hạn hiện tại bao gồm:
    • Chưa hỗ trợ git-lfs: #2812
    • Chưa hỗ trợ sparse repo: #1226
    • Phải thiết lập credential.helper một cách tường minh với HTTPS: #800
  • GitUI hiện không thay thế hoàn toàn Git shell; cách phù hợp là dùng hai công cụ song song
  • Mức ưu tiên tập trung vào các chức năng bất tiện trong Git shell, như stash và staging theo đơn vị line·hunk
  • Dự án hiện là spare time project, và cần sự trợ giúp để biến GitUI thành one stop solution

Cài đặt và build

  • GitUI đang ở trạng thái beta, nên có thể có lỗi và tính năng còn thiếu
  • Công cụ đủ ổn định một cách hợp lý cho sử dụng cá nhân và cũng đang được dùng để phát triển chính GitUI
  • Có thể cài đặt bằng nhiều package manager:
    • Arch Linux: pacman -S gitui
    • Fedora: sudo dnf install gitui
    • openSUSE: sudo zypper install gitui
    • Homebrew: brew install gitui
    • MacPorts: port install gitui
    • Winget: winget install gitui
    • Scoop: scoop install gitui
    • Chocolatey: choco install gitui
    • Mise: mise use -g gitui@latest
    • Termux: pkg install gitui
    • Anaconda: conda install -c conda-forge gitui
  • Binary phát hành được cung cấp cho Linux, macOS, Windows
    • Linux có các gói x86_64, aarch64, arm, armv7
    • macOS có các gói arm64 và Intel x86
    • Windows có binary đơn 64bit và gói cài đặt MSI 64bit
  • Yêu cầu build như sau:
    • Phiên bản rust/cargo được hỗ trợ tối thiểu là 1.88
    • Cần perl 5.12 trở lên và trình biên dịch C để build dependency OpenSSL
    • Cần Python có thể gọi bằng python để chạy toàn bộ test suite
  • Với Cargo, có thể bắt đầu build và cài đặt bằng lệnh cargo install gitui --locked
  • Cargo feature trace-libgit kích hoạt tracing cho libgit2, và hoạt động khi libgit2 được build với -DENABLE_TRACE=ON
  • Feature này được bật mặc định; để tắt, hãy dùng cargo install --no-default-features

Cấu hình, chẩn đoán, tùy biến

  • Logging được kích hoạt bằng gitui -l
  • Vị trí file log khác nhau tùy nền tảng:
    • macOS: $HOME/Library/Caches/gitui/gitui.log
    • Linux with XDG: $XDG_CACHE_HOME/gitui/gitui.log
    • Linux: $HOME/.cache/gitui/gitui.log
    • Windows: %LOCALAPPDATA%/gitui/gitui.log
  • GitUI sẽ tự động hoạt động với cả theme terminal sáng và tối
  • Có thể tùy biến theme màu theo THEMES.md
  • Có thể tùy biến key binding theo KEY_CONFIG.md, và có thể thiết lập binding kiểu vim
  • Các dự án truyền cảm hứng là lazygit, tig, GitUp, git-brunch
  • Về GitUp, có thêm mục tiêu là sẽ tốt nếu tìm được cách dùng map view trong công cụ terminal

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-08
Ý kiến trên Hacker News

  • Ngay sau khi cài đặt, cửa sổ xterm quá nhỏ nên tôi phóng to lên, rồi định kéo mép vùng cây tệp để thu hẹp lại nhưng không thể
    Tôi muốn xem diff lớn hơn, còn tên tệp thì ngắn nên phần lớn vùng cây bị lãng phí, mà trong trợ giúp H cũng không có phím nào liên quan, nên có vẻ như cũng không thể chỉnh kích thước bằng bàn phím
    Dù có thể làm bằng bàn phím đi nữa thì trong trường hợp này đổi kích thước bằng chuột vẫn dễ và nhanh hơn nhiều, và cũng sẽ tốt nếu có chỉnh bằng bàn phím cho những lúc không dùng được chuột, như trong môi trường SSH bị lỗi

    • Việc bổ sung hỗ trợ chuột trong terminal cho các phím tắt thực sự rất hữu ích
      Ngay cả trong Vim, những chỗ tôi vẫn dùng trackpad/chuột là cuộn và chỉnh kích thước cửa sổ, và không có lý do gì mà qua SSH lại không thể hỗ trợ cả hai
      Nó có vẻ cũng sẽ là một tính năng bổ sung hay ở đây

  • lazygit được ghi là nguồn cảm hứng của dự án này, nên với tư cách là người dùng lazygit, tôi tò mò không biết nó còn thiếu gì mà cần hẳn một dự án mới hoàn toàn
    Tôi đang dùng lazygit rất hữu ích

    • Khó nói cách tiếp cận đó có hợp lý không, nhưng nhìn từ góc độ quản lý thì các con số khá ấn tượng
      Để trình bày ở meetup RustBerlin, họ đã parse toàn bộ kho Git của Linux để so sánh lazygit, tig và gitui, và kho đó có hơn 900 nghìn commit
      gitui mất 24 giây, dùng 0.17GB bộ nhớ, binary 1.4MB, không treo, không crash; lazygit mất 57 giây, 2.6GB, 16MB, có treo, thỉnh thoảng crash; còn tig là 4 phút 20 giây, 1.3GB, 0.6MB, thỉnh thoảng treo, không crash
    • Tôi đã dùng lazygit hằng ngày suốt nhiều năm, và vài tháng trước cũng thử cái này, nhưng nó trông giống như một trường hợp viết lại bằng Rust một công cụ gần như hoàn hảo
      Theo tôi nhớ thì nó không có tính năng nào mà lazygit không có, thậm chí còn thiếu một số tính năng đang có trong lazygit
    • README có nói về động lực làm ra nó
      Họ làm hầu hết tác vụ Git trong terminal, nhưng với các việc như index, commit, diff, stash, blame, log thì lại thường dùng Git GUI, và các Git GUI phổ biến hoặc là thất bại hoặc mất phản hồi trên những kho rất lớn nên không dùng được

  • Câu “các Git GUI phổ biến hoặc là thất bại hoặc mất phản hồi trên những kho rất lớn nên không dùng được” là điều tôi chỉ thấy khi git status bị chậm trên dòng lệnh hoặc trong magit do một cây thư mục rất sâu chưa đưa vào .gitignore
    Trong trường hợp như vậy, tôi không thấy có khác biệt giữa việc dùng Git kiểu GUI/TUI/dòng lệnh
    Các giao diện Git khác có thất bại nghiêm trọng hơn chính Git không?

    • Tôi nghĩ kiểu thất bại của Magit là do các thao tác con để kéo thông tin diff vào trang status
      Ngay cả khi gặp cùng vấn đề đó thì git status trên dòng lệnh vẫn gần như kết thúc ngay lập tức
      Việc hiển thị nhiều thông tin thì tất nhiên sẽ tốn thời gian, nhưng magit ở một số điểm hoạt động quá eager nên đôi khi tạo ra luồng công việc đắt hơn rất nhiều so với luồng Git thuần
    • Tôi không bao giờ merge lớn trong magit, mấy việc đó tôi dùng Git CLI
    • Vậy thì khá bất ngờ
      Git UI của IntelliJ được viết bằng Java và còn chạy bên trong IDE mà vẫn đủ nhanh, nên một Git UI độc lập đáng ra không nên là vấn đề

  • Bài liên quan:
    GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 - tháng 9 năm 2022, 90 bình luận
    Terminal-UI for Git written in Rust - https://news.ycombinator.com/item?id=25504811 - tháng 12 năm 2020, 1 bình luận

  • Có ai từng làm một giao diện click-and-drag cho Git chưa?
    Ý là một giao diện cho phép làm việc kiểu cứ kéo thả nhánh là xong

    • Git GUI tôi thích nhất là Fork: https://git-fork.com/
      Nó hỗ trợ drag-and-drop cho nhiều thao tác như merge, rebase, stage/unstage, và có lẽ còn nhiều nữa
    • Tôi dùng GitHub Desktop cho các tác vụ cơ bản, còn việc phức tạp thì dùng CLI
      Nó là một Git client khá đơn giản, nhưng cũng có một chút tính năng kéo thả cho các việc như cherry-pick commit
    • Tôi từng thấy một extension quảng bá chính tính năng như vậy, nhưng chưa dùng thử
      https://marketplace.visualstudio.com/items?itemName=trunkflo...
    • Dù đã 10 năm trôi qua, khi cần click-and-drag trong UI thì tôi vẫn chủ yếu dùng SourceTree

  • Tôi đã thử gần như mọi công cụ kiểu này, nhưng cuối cùng luôn quay lại tig vì lúc nào cũng thiếu một tính năng cốt lõi nào đó hoặc nó không hoạt động theo cách tôi muốn
    Trong GitUI, tôi không tìm thấy cách hiển thị nào thể hiện tốt cấu trúc nhánh ở những nơi như chế độ xem Log
    Sẽ rất tốt nếu có một công cụ thể hiện cấu trúc nhánh rõ ràng để phục vụ việc cân nhắc rebase

  • Trông khá ổn, có lẽ tôi sẽ thử
    Tôi vẫn hy vọng một ngày nào đó GitExtensions sẽ được port thành ứng dụng Linux native
    Tôi đã dùng hàng chục UI nhưng có vẻ không có cái nào sánh bằng nó

    • Từ khi chuyển sang Linux, ứng dụng Windows duy nhất tôi nhớ hằng ngày là TortoiseGit
      Vẫn chưa có Git UI nào giúp dùng hệ thống dựa trên menu ngữ cảnh một cách tự nhiên như TortoiseGit
    • Tôi luôn ngạc nhiên vì có quá ít lập trình viên biết đến GitExtensions
      Git UI duy nhất khác gần giống nó là Tortoise, nhưng trước đây tôi chỉ dùng biến thể hg của nó
    • Gitex rất tuyệt
      Trên Linux tôi vẫn đang dùng bản mono 2.x của nó

  • Nó trông rất giống plugin Neovim neogit mà tôi bắt đầu dùng từ khoảng một tháng trước
    Key binding hơi gượng gạo, và tôi mất khoảng một giờ để thực sự quen với toàn bộ workflow, nhưng sau khi quen rồi thì nó nhanh hơn nhiều so với cách cũ là suspend neovim rồi dùng Git trực tiếp trong shell
    0: https://github.com/NeogitOrg/neogit

  • Một trong những điều khiến tôi lo ngại về các công cụ UI là chúng thường che giấu các lệnh thực sự khỏi người dùng, khiến sau này khó suy ra chuyện gì đã sai và làm sao tránh lặp lại
    Ví dụ, một số công cụ có thể gắn thêm những flag khá áp đặt, không phù hợp với luồng CLI thông thường
    Tôi không biết công cụ này có như vậy không, nhưng đây có thể là một phản hồi đáng chú ý cho nhóm công cụ cùng loại này

    • Vì thế trên Windows tôi dùng và thích GitExtensions
      Nó luôn hiển thị đầy đủ các lệnh đang chạy, và bạn cũng có thể xem toàn bộ log một cách trọn vẹn