Technische Neuigkeiten zu GitUI

 (github.com/extrawurst)
10 Punkte von GN⁺ 2024-01-08 | 1 Kommentare | Auf WhatsApp teilen
  • GitUI ist ein Tool, das die Nutzbarkeit und den Komfort einer Git-GUI im Terminal bietet, und entstand aus dem Anwendungsfall von Nutzern, die erlebt haben, dass bestehende Git-GUIs bei riesigen Repositories hängen bleiben oder langsam werden
  • Zu den Hauptfunktionen gehören ausschließliche Tastaturbedienung, kontextbasierte Hilfe, Änderungen prüfen, committen und amend, stage/unstage/revert/reset auf Datei-, Hunk- und Zeilenebene, Stash, Push/Fetch, Branch-Verwaltung sowie das Durchsuchen des Commit-Logs und das Anzeigen von Diffs
  • In einem Vergleich, bei dem mehr als 900.000 Commits des Linux-Git-Repositories geparst wurden, erreichte gitui 24 Sekunden bei 0,17 GB Speicher, lazygit 57 Sekunden und 2,6 GB, tig 4 Minuten 20 Sekunden und 1,3 GB
  • Zu den Zielen vor Version 1.0 gehören die Visualisierung der Branch-Struktur im Log-Tab und Interactive Rebase; bekannte Einschränkungen gibt es bei git-lfs, Sparse Repos und der automatischen Behandlung von credential.helper für HTTPS
  • Derzeit ersetzt es die Git-Shell nicht vollständig, sondern ist eher ein ergänzendes Tool für Aufgaben, die in der Git-Shell umständlich sind, etwa Stash oder Staging auf Zeilen- und Hunk-Ebene

Ein Tool, das die Git-GUI-Erfahrung ins Terminal bringt

  • GitUI ist ein Open-Source-Tool, das die Benutzererfahrung und den Komfort einer Git-GUI im Terminal bereitstellt
  • Die Motivation entstand aus der Erfahrung, die meisten Git-Aufgaben im Terminal zu erledigen, aber für Dinge wie Index, Commit, Diff, Stash, Blame und Log dennoch häufig eine Git-GUI zu verwenden
  • Bestehende populäre Git-GUIs hatten das Problem, dass sie bei riesigen Repositories scheitern, nicht mehr reagieren und unbenutzbar werden
  • GitUI zielt auf eine Git-GUI-Erfahrung im Terminal ab, die portable, fast, free und opensource ist

Funktionsumfang

  • Das Bedienmodell konzentriert sich auf reine Tastatursteuerung und kontextbasierte Hilfe und ist so gestaltet, dass man sich nicht viele Shortcuts merken muss
  • Die Arbeit mit Änderungen umfasst Folgendes
    • Änderungen prüfen, committen, amend
    • einschließlich der Hooks pre-commit, commit-msg, post-commit, prepare-commit-msg
    • stage, unstage, revert, reset auf Datei-, Hunk- und Zeilenebene
  • Auch Repository-Workflows werden unterstützt
    • Stash speichern, pop, apply, drop, inspect
    • zu Remotes pushen, von Remotes fetchen
    • Branches erstellen, umbenennen, löschen, checkouten, Remotes anzeigen
    • Commit-Log durchsuchen und suchen, Diffs von committeten Änderungen anzeigen
  • Zur UI und zur internen Funktionsweise gehören eine reaktionsfähige Terminal-UI, eine asynchrone Git-API für flüssige Bedienung und Submodule-Unterstützung
  • GPG Commit Signing wird unterstützt, es gibt aber Einschränkungen in #97

Benchmark-Ergebnisse

  • In einem Vortrag beim RustBerlin-Meetup wurden lazygit, tig und gitui verglichen, indem das gesamte Linux-Git-Repository geparst wurde
  • Die Vergleichsergebnisse lauten wie folgt
    • gitui: 24 Sekunden, 0,17 GB Speicher, 10 MB Binärdatei, kein Freeze, kein Crash
    • lazygit: 57 Sekunden, 2,6 GB Speicher, 25 MB Binärdatei, Freeze vorhanden, Crashs treten gelegentlich auf
    • tig: 4 Minuten 20 Sekunden, 1,3 GB Speicher, 0,6 MB Binärdatei, gelegentliche Freezes, keine Crashs
  • gitui erzielte in diesem Vergleich die niedrigsten Werte bei Zeit und Speicher

Roadmap vor 1.0 und bekannte Einschränkungen

  • Vor der Bezeichnung 1.0 gibt es zwei übergeordnete Ziele
    • Visualisierung der Branch-Struktur im Log-Tab: #81
    • Interactive Rebase: #32
  • Zu den aktuellen Einschränkungen gehören
    • keine Unterstützung für git-lfs: #2812
    • keine Unterstützung für Sparse Repos: #1226
    • bei HTTPS muss credential.helper explizit gesetzt werden: #800
  • GitUI ersetzt die Git-Shell derzeit nicht vollständig; die gemeinsame Nutzung beider Werkzeuge passt gut zusammen
  • Die Priorität liegt auf Funktionen, die in der Git-Shell umständlich sind, etwa Stash oder Staging auf Zeilen- und Hunk-Ebene
  • Das Projekt ist derzeit ein Spare-Time-Projekt, und um GitUI zu einer One-Stop-Solution zu machen, wird Hilfe benötigt

Installation und Build

  • GitUI befindet sich im Beta-Status, daher kann es Bugs und fehlende Funktionen geben
  • Für den persönlichen Einsatz ist es angemessen stabil und wird auch für die Entwicklung von GitUI selbst verwendet
  • Die Installation ist über verschiedene Paketmanager möglich
    • 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
  • Release-Binärdateien werden für Linux, macOS und Windows bereitgestellt
    • Für Linux gibt es Pakete für x86_64, aarch64, arm und armv7
    • Für macOS gibt es Pakete für arm64 und Intel x86
    • Für Windows gibt es eine einzelne 64-Bit-Binärdatei und ein 64-Bit-MSI-Installationspaket
  • Die Build-Anforderungen sind wie folgt
    • Die minimal unterstützte rust-/cargo-Version ist 1.88
    • Für den Build der OpenSSL-Abhängigkeit werden perl 5.12 oder höher und ein C-Compiler benötigt
    • Für die Ausführung der vollständigen Test-Suite wird Python benötigt, das über python aufrufbar ist
  • Mit Cargo kann der Build und die Installation per cargo install gitui --locked gestartet werden
  • Das Cargo-Feature trace-libgit aktiviert libgit2-Tracing und funktioniert, wenn libgit2 mit -DENABLE_TRACE=ON gebaut wurde
  • Dieses Feature ist standardmäßig aktiviert; zum Deaktivieren wird cargo install --no-default-features verwendet

Konfiguration, Diagnose und Anpassung

  • Logging wird mit gitui -l aktiviert
  • Der Speicherort der Log-Datei unterscheidet sich je nach Plattform
    • macOS: $HOME/Library/Caches/gitui/gitui.log
    • Linux mit XDG: $XDG_CACHE_HOME/gitui/gitui.log
    • Linux: $HOME/.cache/gitui/gitui.log
    • Windows: %LOCALAPPDATA%/gitui/gitui.log
  • GitUI sollte sowohl mit hellen als auch mit dunklen Terminal-Themes automatisch funktionieren
  • Das Farb-Theme kann gemäß THEMES.md nach Wunsch angepasst werden
  • Die Tastenbelegung kann gemäß KEY_CONFIG.md angepasst und auf vim-artige Bindings eingestellt werden
  • Als Inspirationsquellen werden lazygit, tig, GitUp und git-brunch genannt
  • Zu GitUp wird zusätzlich das Ziel erwähnt, einen Weg zu finden, eine Map-Ansicht in einem Terminal-Tool zu nutzen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-08
Meinungen auf Hacker News

  • Direkt nach der Installation war das xterm-Fenster zu klein, also habe ich es vergrößert und versucht, den Rand des Dateibaum-Bereichs per Drag zu verkleinern, aber das ging nicht.
    Ich wollte den Diff größer sehen, und weil die Dateinamen kurz waren, war der größte Teil des Baum-Bereichs verschwendet. Auch in der H-Hilfe gab es keine entsprechende Taste, also scheint Größenänderung per Tastatur ebenfalls nicht möglich zu sein.
    Selbst wenn es per Tastatur möglich wäre, ist in solchen Fällen Resize per Maus viel einfacher und schneller; zusätzlich wäre eine Tastatursteuerung gut für Situationen, in denen man die Maus nicht nutzen kann, etwa in einer kaputten SSH-Umgebung.

    • Terminal-Mausunterstützung als Ergänzung zu Tastenkürzeln ist wirklich nützlich.
      Auch in Vim nutze ich Trackpad/Maus weiterhin fürs Scrollen und zum Ändern der Fenstergröße, und es gibt keinen Grund, warum beides nicht auch über SSH hinweg angeboten werden sollte.
      Das wäre auch hier eine gute Ergänzung.

  • lazygit wird als Inspiration für dieses Projekt genannt; als lazygit-Nutzer frage ich mich, was daran gefehlt hat, dass ein komplett neues Projekt nötig war.
    Ich nutze lazygit sehr gern.

    • Ob die Methodik sinnvoll ist, kann ich schwer beurteilen, aber aus Sicht eines Managers sind die Zahlen ziemlich beeindruckend.
      Für einen Vortrag beim RustBerlin-Meetup wurde das gesamte Linux-Git-Repository geparst, um lazygit, tig und gitui zu vergleichen; das Repository hatte mehr als 900.000 Commits.
      gitui brauchte 24 Sekunden, 0,17 GB Speicher, hatte ein 1,4-MB-Binary, keine Hänger und keine Abstürze; lazygit brauchte 57 Sekunden, 2,6 GB, 16 MB, hatte Hänger und gelegentliche Abstürze; tig brauchte 4 Minuten 20 Sekunden, 1,3 GB, 0,6 MB, hatte gelegentliche Hänger und keine Abstürze.
    • Ich nutze lazygit seit Jahren täglich und habe das hier vor ein paar Monaten auch ausprobiert; es wirkte wie ein Fall von ein nahezu perfektes Tool in Rust neu schreiben.
      Soweit ich mich erinnere, gab es keine Funktion, die lazygit nicht hatte; im Gegenteil fehlten einige Funktionen, die lazygit bietet.
    • Die Motivation steht im README.
      Die meisten Git-Arbeiten passieren zwar im Terminal, aber für Dinge wie Index, Commit, Diff, Stash, Blame und Log habe man häufig eine Git-GUI genutzt, und populäre Git-GUIs seien bei riesigen Repositories fehlgeschlagen oder nicht mehr responsiv geworden und dadurch unbrauchbar gewesen.

  • Die Aussage „populäre Git-GUIs schlagen bei riesigen Repositories fehl oder reagieren nicht mehr“ habe ich nur dann erlebt, wenn git status wegen eines sehr tiefen Verzeichnisbaums, der noch nicht in .gitignore stand, auf der Kommandozeile oder in magit lange dauerte.
    In solchen Fällen sehe ich keinen Unterschied zwischen der Nutzung von Git per GUI, TUI oder Kommandozeile.
    Scheitern andere Git-Interfaces dramatischer als Git selbst?

    • Ich denke, Magits Fehlverhalten kommt von Unteroperationen, die auf der Status-Seite Diff-Informationen holen.
      Bei demselben Problem war git status auf der Kommandozeile fast sofort fertig.
      Dass das Anzeigen vieler Informationen Zeit braucht, lässt sich nicht vermeiden, aber magit ist an manchen Stellen zu eager und erzeugt dadurch manchmal Workflows, die deutlich teurer sind als der rohe Git-Ablauf.
    • Große Merges mache ich nie in magit; dafür nutze ich die Git-CLI.
    • Dann überrascht mich das.
      IntelliJs Git-UI ist in Java geschrieben und in die IDE integriert, ist aber trotzdem schnell genug; eine externe Git-UI sollte also eigentlich keine Probleme haben.

  • Verwandte Beiträge:
    GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 - September 2022, 90 Kommentare
    Terminal-UI for Git written in Rust - https://news.ycombinator.com/item?id=25504811 - Dezember 2020, 1 Kommentar

  • Hat jemand eine Click-and-Drag-UI für Git gebaut?
    Ich meine eine UI, in der man Branches einfach per Drag-and-Drop verschieben kann, um damit zu arbeiten.

    • Meine liebste Git-GUI ist Fork: https://git-fork.com/
      Sie unterstützt Drag-and-Drop für verschiedene Aktionen wie Merge, Rebase, Stage/Unstage und vermutlich noch mehr.
    • Für grundlegende Aufgaben nutze ich GitHub Desktop und für Komplexeres die CLI.
      Es ist ein ziemlich einfacher Git-Client, hat aber ein wenig Drag-Funktionalität für Dinge wie das Cherry-Picken von Commits.
    • Ich habe mal eine Erweiterung gesehen, die so etwas als eines ihrer beworbenen Features herausstellte, habe sie aber nicht ausprobiert.
      https://marketplace.visualstudio.com/items?itemName=trunkflo...
    • Auch nach 10 Jahren nutze ich, wenn ich in einer UI Click-and-Drag brauche, immer noch hauptsächlich SourceTree.

  • Ich probiere all diese Tools aus, aber immer fehlt eine Kernfunktion oder etwas funktioniert nicht so, wie ich es möchte, sodass ich am Ende wieder zu tig zurückkehre.
    In GitUI konnte ich keine Anzeige finden, die etwa in der Log-Ansicht die Branch-Struktur gut darstellt.
    Ich hätte gern ein Tool, das die Branch-Struktur mit Blick auf Rebase gut sichtbar macht.

  • Sieht gut aus, ich werde es ausprobieren.
    Ich hoffe, dass GitExtensions irgendwann als native Linux-Anwendung portiert wird.
    Ich habe Dutzende UIs ausprobiert, aber nichts scheint daran heranzukommen.

    • Die einzige Windows-App, die ich nach dem Wechsel zu Linux täglich vermisse, ist TortoiseGit.
      Es gab bisher keine Git-UI, die ein kontextmenübasiertes System so natürlich nutzbar macht wie TortoiseGit.
    • Ich bin immer wieder überrascht, dass so wenige Entwickler GitExtensions kennen.
      Die einzige andere Git-UI, die dem nahekommt, ist Tortoise, wobei ich früher nur die hg-Variante benutzt habe.
    • Gitex ist großartig.
      Unter Linux nutze ich immer noch die 2.x-Mono-Version.

  • Es sieht dem Neovim-Plugin neogit, das ich seit etwa einem Monat nutze, sehr ähnlich.
    Die Keybindings waren etwas rau, und es hat ungefähr eine Stunde gedauert, bis ich mit dem gesamten Workflow wirklich vertraut war; danach war ich aber viel schneller als mit meiner bisherigen Methode, neovim zu suspendieren und Git direkt in der Shell zu verwenden.
    0: https://github.com/NeogitOrg/neogit

  • Eine meiner Sorgen bei UI-Tools ist, dass sie die tatsächlich ausgeführten Befehle oft vor dem Nutzer verbergen, wodurch es später schwer wird, nachzuvollziehen, was schiefgelaufen ist und wie man es künftig vermeidet.
    Manche Tools setzen zum Beispiel recht eigenwillige Flags, die nicht zum üblichen CLI-Flow passen.
    Ich weiß nicht, ob das auf dieses Tool zutrifft, aber für diese Tool-Kategorie könnte das ein interessantes Feedback sein.

    • Deshalb nutze und mag ich unter Windows GitExtensions.
      Es zeigt immer den vollständigen ausgeführten Befehl, und auch das komplette Log ist vollständig einsehbar.