GitUI ile ilgili teknik gelişmeler

 (github.com/extrawurst)
10 puan yazan GN⁺ 2024-01-08 | 1 yorum | WhatsApp'ta paylaş
  • GitUI, terminal içinde Git GUI’nin kullanılabilirliğini ve rahatlığını sunan bir araçtır; büyük depolarda mevcut Git GUI’lerin donması ya da yavaşlaması sorununu yaşayan kullanım örneklerinden yola çıkmıştır
  • Başlıca özellikleri arasında yalnızca klavye ile kullanım, bağlama dayalı yardım, değişiklikleri inceleme·commit·amend, dosya·hunk·satır düzeyinde stage/unstage/revert/reset, stash, push/fetch, branch yönetimi, commit log arama ve diff görüntüleme yer alır
  • Linux Git deposundaki 900 binden fazla commit’in parse edildiği karşılaştırmada gitui 24 saniye ve 0.17GB bellek kaydederken, lazygit 57 saniye·2.6GB, tig ise 4 dakika 20 saniye·1.3GB kaydetti
  • 1.0 öncesi hedefler arasında log sekmesinde branch yapısının görselleştirilmesi ve interactive rebase bulunuyor; git-lfs, sparse repo ve HTTPS için credential.helper otomatik işleme tarafında bilinen sınırlamalar var
  • Şu anda Git shell’in yerini tamamen almıyor; daha çok stash ya da satır·hunk düzeyinde staging gibi Git shell’de zahmetli işleri tamamlayan ve onunla birlikte kullanılan bir araç niteliğinde

Git GUI deneyimini terminale taşıyan araç

  • GitUI, terminalde Git GUI’nin kullanıcı deneyimini ve rahatlığını sunan açık kaynaklı bir araçtır
  • Geliştirme motivasyonu, Git işlemlerinin çoğunu terminalde yaparken index, commit, diff, stash, blame, log gibi işlerde yine de sık sık Git GUI kullanma deneyiminden doğdu
  • Mevcut popüler Git GUI’lerde, çok büyük depolarda başarısız olma ya da yanıt vermeyip kullanılamaz hale gelme sorunu vardı
  • GitUI, terminal içinde portable, fast, free, opensource bir Git GUI deneyimi sunmayı hedefliyor

Özellik kapsamı

  • Kullanım modeli, yalnızca klavye ile kontrol ve bağlama dayalı yardım etrafında şekilleniyor; çok sayıda kısayolu ezberlemeyi gerektirmeyecek şekilde tasarlanmış
  • Değişikliklerle ilgili işlemler şunları içeriyor
    • değişiklikleri inceleme, commit, amend
    • pre-commit, commit-msg, post-commit, prepare-commit-msg hook’ları dahil
    • dosya, hunk ve satır düzeyinde stage, unstage, revert, reset
  • Depo akışıyla ilgili işlemler de destekleniyor
    • stash kaydetme, pop, apply, drop, inspect
    • remote’a push, remote’tan fetch
    • branch oluşturma, yeniden adlandırma, silme, checkout, remotes görüntüleme
    • commit log gezinme ve arama, commit edilmiş değişikliklerin diff’ini görüntüleme
  • UI ve iç işleyiş tarafında tepkisel terminal arayüzü, akıcı kullanım için asenkron Git API’si ve submodule desteği bulunuyor
  • GPG commit signing destekleniyor ancak #97 ile ilgili bazı kısıtlar var

Benchmark sonuçları

  • RustBerlin meetup sunumunda lazygit, tig ve gitui, Linux Git deposunun tamamını parse etme üzerinden karşılaştırıldı
  • Karşılaştırma sonuçları şöyle
    • gitui: 24 saniye, 0.17GB bellek, 10MB binary, donma yok, çökme yok
    • lazygit: 57 saniye, 2.6GB bellek, 25MB binary, donma var, çökme ara sıra oluyor
    • tig: 4 dakika 20 saniye, 1.3GB bellek, 0.6MB binary, donma ara sıra oluyor, çökme yok
  • gitui, bu karşılaştırmada süre ve bellek kategorilerinde en düşük değerleri kaydetti

1.0 öncesi yol haritası ve bilinen sınırlamalar

  • 1.0 olarak adlandırılmadan önceki iki ana hedef şunlar
    • log sekmesinde branch yapısının görselleştirilmesi: #81
    • interactive rebase: #32
  • Mevcut sınırlamalar arasında şunlar bulunuyor
    • git-lfs desteği yok: #2812
    • sparse repo desteği yok: #1226
    • HTTPS üzerinde credential.helper ayarının açıkça yapılması gerekiyor: #800
  • GitUI şu anda Git shell’in yerini tamamen almıyor; iki aracı birlikte kullanmak daha uygun bir yaklaşım
  • Öncelik, stash veya satır·hunk düzeyinde staging gibi Git shell’de zahmetli olan işlevlere verilmiş durumda
  • Proje şu anda bir spare time project ve GitUI’yi one stop solution haline getirmek için yardıma ihtiyaç duyuluyor

Kurulum ve derleme

  • GitUI beta durumunda ve hata ya da eksik özellikler içerebilir
  • Kişisel kullanım için makul ölçüde kararlı ve GitUI’nin kendi geliştirilmesinde de kullanılıyor
  • Çeşitli paket yöneticileriyle kurulabiliyor
    • 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
  • Yayınlanan binary’ler Linux, macOS ve Windows için sunuluyor
    • Linux için x86_64, aarch64, arm, armv7 paketleri mevcut
    • macOS için arm64 ve Intel x86 paketleri mevcut
    • Windows için 64bit tek binary ve 64bit MSI kurulum paketi mevcut
  • Derleme gereksinimleri şöyle
    • desteklenen en düşük rust/cargo sürümü 1.88
    • OpenSSL bağımlılığını derlemek için perl 5.12 veya üzeri ve bir C derleyicisi gerekiyor
    • tam test paketini çalıştırmak için python ile çağrılabilen bir Python kurulumu gerekiyor
  • Cargo ile derleme ve kurulum cargo install gitui --locked komutuyla başlatılabiliyor
  • trace-libgit Cargo feature’ı libgit2 tracing’i etkinleştirir; libgit2 -DENABLE_TRACE=ON ile derlenmişse çalışır
  • Bu feature varsayılan olarak etkin; devre dışı bırakmak için cargo install --no-default-features kullanılır

Yapılandırma, tanılama ve özelleştirme

  • Logging, gitui -l ile etkinleştirilir
  • Log dosyasının konumu platforma göre değişir
    • 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, hem light hem de dark terminal temalarında otomatik olarak çalışmalıdır
  • Renk temaları THEMES.md doğrultusunda istenildiği gibi özelleştirilebilir
  • Tuş atamaları KEY_CONFIG.md doğrultusunda özelleştirilebilir ve vim tarzı bağlamalar olarak ayarlanabilir
  • İlham alınan projeler lazygit, tig, GitUp, git-brunch oldu
  • GitUp için ayrıca, terminal aracında map view kullanmanın bir yolunu bulma hedefi de ekleniyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-08
Hacker News yorumları

  • Kurar kurmaz xterm penceresi çok küçük olduğu için büyüttüm; dosya ağacı alanının kenarını sürükleyip daraltmaya çalıştım ama mümkün olmadı.
    Diff’i daha büyük görmek istiyordum; dosya adları da kısa olduğundan ağaç alanının büyük kısmı boşa gidiyordu. H yardımında da ilgili bir tuş olmadığı için klavyeyle de yeniden boyutlandırma yok gibi görünüyor.
    Klavyeyle mümkün olsa bile bu tür durumlarda fareyle yeniden boyutlandırma çok daha kolay ve hızlı; bozuk bir SSH ortamı gibi farenin kullanılamadığı durumlar için klavyeyle ayarlama da olsa iyi olurdu.

    • Klavye kısayollarına ek olarak terminal fare desteği sunmak gerçekten faydalı.
      Vim’de bile trackpad/fareyi hâlâ kullandığım yerler kaydırma ve pencere boyutlandırma; SSH üzerinden de ikisini birden sunmamak için bir neden yok.
      Buraya da iyi bir ek özellik olur gibi.

  • lazygit bu projenin ilham kaynağı olarak yazılmış; bir lazygit kullanıcısı olarak, tamamen yeni bir projeye ihtiyaç duyuracak neyin eksik olduğunu merak ediyorum.
    lazygit’i çok faydalı buluyorum.

    • Metodolojinin geçerli olup olmadığını değerlendirmek zor, ama bir yöneticinin gözünden bakınca sayılar oldukça etkileyici.
      RustBerlin meetup sunumu için tüm Linux Git deposu parse edilerek lazygit, tig ve gitui karşılaştırılmış; depoda 900 binden fazla commit varmış.
      gitui 24 saniye, 0,17 GB bellek, 1,4 MB binary, takılma yok, çökme yok; lazygit 57 saniye, 2,6 GB, 16 MB, takılma var, ara sıra çökme; tig ise 4 dakika 20 saniye, 1,3 GB, 0,6 MB, ara sıra takılma, çökme yok şeklindeymiş.
    • Birkaç yıldır lazygit’i her gün kullanıyorum, birkaç ay önce bunu da denedim; neredeyse kusursuz bir aracı Rust ile yeniden yazmak için yapılmış bir örnek gibi göründü.
      Hatırladığım kadarıyla lazygit’te olmayan bir özellik yoktu; aksine lazygit’te bulunan bazı özellikler eksikti.
    • Motivasyon README’de yazıyor.
      Çoğu Git işini terminalde yapsalar da index, commit, diff, stash, blame, log gibi işler için sık sık Git GUI kullandıklarını; popüler Git GUI’lerinin ise devasa depolarda başarısız olduğunu ya da yanıtsız kalıp kullanılamaz hâle geldiğini söylüyor.

  • “Popüler Git GUI’leri devasa depolarda başarısız oluyor ya da yanıtsız kalıp kullanılamaz hâle geliyor” ifadesini, yalnızca .gitignore’a henüz eklenmemiş çok derin bir dizin ağacı yüzünden git status komut satırında veya magit’te uzun sürdüğünde gördüm.
    Böyle durumlarda GUI/TUI/komut satırı Git kullanımı arasında fark olmadığını düşünüyorum.
    Diğer Git arayüzleri Git’in kendisinden daha dramatik biçimde mi başarısız oluyor?

    • Magit’in başarısızlık biçiminin, status sayfasında diff bilgisi çekmeye yönelik alt işlemlerden kaynaklandığını düşünüyorum.
      Aynı sorun varken bile komut satırında git status neredeyse anında bitiyordu.
      Çok bilgi göstermek zaman alır, bu kaçınılmaz; ama magit bazı noktalarda fazla eager davranıp ham Git akışından çok daha pahalı iş akışları oluşturabiliyor.
    • Büyük merge’leri magit’te asla yapmıyorum; onlar için Git CLI kullanıyorum.
    • Öyleyse şaşırtıcı.
      IntelliJ’in Git UI’ı Java ile yazılmış ve IDE’nin içinde yer almasına rağmen yeterince hızlı; dış bir Git UI’da sorun olmaması gerekir gibi.

  • İlgili yazılar:
    GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 - Eylül 2022, 90 yorum
    Terminal-UI for Git written in Rust - https://news.ycombinator.com/item?id=25504811 - Aralık 2020, 1 yorum

  • Git’te tıkla ve sürükle UI yapan biri var mı?
    Branch’leri sadece sürükleyip bırakarak çalışılabilen bir UI’dan bahsediyorum.

    • En sevdiğim Git GUI Fork: https://git-fork.com/
      merge, rebase, stage/unstage gibi birçok işlemde sürükle-bırak destekliyor; muhtemelen daha fazlası da vardır.
    • Temel işler için GitHub Desktop, karmaşık işler için CLI kullanıyorum.
      Oldukça basit bir Git istemcisi, ama commit cherry-pick gibi işlemler için biraz sürükleme işlevi var.
    • Reklamını yaptığı özelliklerden biri olarak bunu öne çıkaran bir eklenti görmüştüm, ama denemedim.
      https://marketplace.visualstudio.com/items?itemName=trunkflo...
    • 10 yıl geçse de UI’da tıkla-sürükle gerektiğinde hâlâ çoğunlukla SourceTree kullanıyorum.

  • Bu tür araçların hepsini deniyorum, ama hep temel bir özellik eksik oluyor ya da istediğim şekilde çalışmıyor; sonunda tig’e geri dönüyorum.
    GitUI’da Log görünümü gibi yerlerde branch yapısını iyi gösteren bir gösterim bulamadım.
    Rebase’i düşünerek branch yapısını iyi gösteren bir araç olsa iyi olurdu.

  • Güzel görünüyor, denemeyi düşünüyorum.
    Bir gün GitExtensions’ın native bir Linux uygulamasına port edilmesini umuyorum.
    Düzinelerce UI denedim ama onun gibisi yok gibi.

    • Linux’a geçtikten sonra her gün özlediğim tek Windows uygulaması TortoiseGit.
      Bağlam menüsü tabanlı sistemi TortoiseGit kadar doğal kullandıran bir Git UI henüz olmadı.
    • GitExtensions’ı bilen geliştirici sayısının bu kadar az olmasına hep şaşırıyorum.
      Ona yaklaşan diğer tek Git UI Tortoise; onda da eskiden yalnızca hg varyantını kullanmıştım.
    • Gitex harika.
      Linux’ta hâlâ 2.x mono sürümünü kullanıyorum.

  • Yaklaşık bir ay önce kullanmaya başladığım Neovim eklentisi neogit’e çok benziyor.
    Key binding’ler biraz pürüzlüydü ve tüm iş akışına gerçekten alışmam yaklaşık bir saat sürdü; ama alıştıktan sonra önceki yöntemim olan neovim’i suspend edip shell’de Git’i doğrudan kullanmaktan çok daha hızlı hâle geldi.
    0: https://github.com/NeogitOrg/neogit

  • UI araçlarıyla ilgili endişelerimden biri, gerçek komutları çoğu zaman kullanıcıdan gizlemeleri; bu da sonradan neyin yanlış gittiğini ve ileride nasıl kaçınılacağını anlamayı zorlaştırıyor.
    Örneğin bazı araçlar, normal CLI akışıyla uyuşmayan oldukça kendine özgü flag’ler ekleyebilir.
    Bunun bu araç için geçerli olup olmadığını bilmiyorum, ama bu kategorideki araçlar için ilginç bir geri bildirim olabilir.

    • Bu yüzden Windows’ta GitExtensions kullanıyorum ve seviyorum.
      Çalıştırdığı komutun tamamını her zaman gösteriyor; tam log’u da eksiksiz görebiliyorsunuz.