Actualités techniques autour de GitUI

 (github.com/extrawurst)
10 points par GN⁺ 2024-01-08 | 1 commentaires | Partager sur WhatsApp
  • GitUI est un outil qui apporte l’ergonomie et la praticité d’une interface Git GUI dans le terminal, né d’un cas d’usage où les interfaces Git GUI existantes se bloquaient ou devenaient lentes sur de très grands dépôts
  • Ses principales fonctionnalités incluent une navigation entièrement au clavier, une aide contextuelle, l’inspection des changements, le commit et l’amend, ainsi que stage/unstage/revert/reset au niveau du fichier, du hunk et de la ligne, sans oublier stash, push/fetch, la gestion des branches, la recherche dans l’historique des commits et l’affichage des diff
  • Dans une comparaison portant sur l’analyse de plus de 900 000 commits du dépôt Git de Linux, gitui a enregistré 24 secondes et 0,17 Go de mémoire, contre 57 secondes et 2,6 Go pour lazygit, et 4 min 20 s et 1,3 Go pour tig
  • Avant la version 1.0, les objectifs incluent la visualisation de la structure des branches dans l’onglet log et l’interactive rebase, avec des limitations connues concernant git-lfs, les sparse repo et la gestion automatique de credential.helper pour HTTPS
  • À ce stade, GitUI ne remplace pas complètement le shell Git, mais s’utilise plutôt en complément pour simplifier des tâches peu pratiques dans le shell Git, comme stash ou le staging au niveau ligne/hunk

Un outil qui apporte l’expérience d’un Git GUI dans le terminal

  • GitUI est un outil open source qui apporte dans le terminal l’expérience utilisateur et le confort d’un Git GUI
  • La motivation du développement vient de l’expérience consistant à effectuer la plupart des opérations Git dans le terminal, tout en revenant souvent à un Git GUI pour des tâches comme index, commit, diff, stash, blame ou log
  • Les Git GUI populaires existants rencontraient des problèmes sur les très gros dépôts, allant jusqu’à l’échec, l’absence de réponse ou l’impossibilité d’utilisation
  • GitUI vise une expérience de Git GUI dans le terminal qui soit portable, fast, free et opensource

Périmètre fonctionnel

  • Le modèle d’interaction repose sur un contrôle entièrement au clavier et une aide contextuelle, avec une conception pensée pour éviter d’avoir à mémoriser trop de raccourcis
  • Les opérations sur les changements incluent notamment
    • inspection des changements, commit, amend
    • prise en charge des hooks pre-commit, commit-msg, post-commit, prepare-commit-msg
    • stage, unstage, revert et reset au niveau du fichier, du hunk et de la ligne
  • Les opérations liées au flux du dépôt sont également prises en charge
    • enregistrement, pop, apply, drop et inspection du stash
    • push vers un remote, fetch depuis un remote
    • création, renommage, suppression et checkout de branches, affichage des remotes
    • exploration de l’historique des commits, recherche et consultation du diff des changements commités
  • L’interface et le fonctionnement interne incluent une UI terminal réactive, une API Git asynchrone pour une interaction fluide, ainsi que la prise en charge des submodules
  • La signature de commit GPG est prise en charge, avec toutefois des limitations liées à #97

Résultats de benchmark

  • Lors d’une présentation au meetup RustBerlin, lazygit, tig et gitui ont été comparés en analysant l’ensemble du dépôt Git de Linux
  • Les résultats sont les suivants
    • gitui : 24 secondes, 0,17 Go de mémoire, binaire de 10 Mo, aucun freeze, aucun crash
    • lazygit : 57 secondes, 2,6 Go de mémoire, binaire de 25 Mo, freeze présent, crash occasionnel
    • tig : 4 min 20 s, 1,3 Go de mémoire, binaire de 0,6 Mo, freeze occasionnel, aucun crash
  • gitui a obtenu les valeurs les plus basses de cette comparaison en temps et en mémoire

Feuille de route avant la 1.0 et limitations connues

  • Il y a deux objectifs prioritaires avant de parler de version 1.0
    • visualisation de la structure des branches dans l’onglet log : #81
    • interactive rebase : #32
  • Les limitations actuelles incluent notamment
    • absence de prise en charge de git-lfs : #2812
    • absence de prise en charge des sparse repo : #1226
    • nécessité de configurer explicitement credential.helper en HTTPS : #800
  • GitUI ne remplace pas encore complètement le shell Git, et les deux outils se complètent bien dans l’usage
  • La priorité est mise sur des fonctions peu pratiques dans le shell Git, comme stash ou le staging au niveau ligne/hunk
  • Le projet est actuellement un projet mené sur le temps libre, et il a besoin d’aide pour faire de GitUI une solution tout-en-un

Installation et build

  • GitUI est en beta et peut comporter des bugs ainsi que des fonctionnalités manquantes
  • Il est raisonnablement stable pour un usage personnel, et sert aussi au développement de GitUI lui-même
  • Il peut être installé via plusieurs gestionnaires de paquets
    • 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
  • Des binaires de release sont proposés pour Linux, macOS et Windows
    • pour Linux, des paquets existent en x86_64, aarch64, arm et armv7
    • pour macOS, des paquets sont disponibles pour arm64 et Intel x86
    • pour Windows, un binaire 64 bits unique et un paquet d’installation MSI 64 bits sont proposés
  • Les prérequis de build sont les suivants
    • la version minimale prise en charge de rust/cargo est 1.88
    • pour construire les dépendances OpenSSL, il faut perl 5.12 ou supérieur ainsi qu’un compilateur C
    • l’exécution de l’ensemble de la suite de tests nécessite une version de Python appelable via python
  • Avec Cargo, il est possible de lancer la compilation et l’installation via la commande cargo install gitui --locked
  • La feature Cargo trace-libgit active le tracing de libgit2, et fonctionne si libgit2 a été compilé avec -DENABLE_TRACE=ON
  • Cette feature est activée par défaut ; pour la désactiver, il faut utiliser cargo install --no-default-features

Configuration, diagnostic et personnalisation

  • Le logging s’active avec gitui -l
  • L’emplacement du fichier de log varie selon la plateforme
    • macOS : $HOME/Library/Caches/gitui/gitui.log
    • Linux avec XDG : $XDG_CACHE_HOME/gitui/gitui.log
    • Linux : $HOME/.cache/gitui/gitui.log
    • Windows : %LOCALAPPDATA%/gitui/gitui.log
  • GitUI doit fonctionner automatiquement aussi bien avec les thèmes de terminal clairs que sombres
  • Le thème de couleurs peut être personnalisé librement selon THEMES.md
  • Les raccourcis clavier peuvent être personnalisés selon KEY_CONFIG.md, y compris avec des bindings de style vim
  • Les projets cités comme inspirations sont lazygit, tig, GitUp et git-brunch
  • À propos de GitUp, l’objectif supplémentaire mentionné est de trouver un moyen d’utiliser une map view dans un outil terminal

À lire aussi

1 commentaires

 
GN⁺ 2024-01-08
Avis sur Hacker News

  • Juste après l’installation, la fenêtre xterm était beaucoup trop petite ; j’ai voulu l’agrandir puis réduire la zone de l’arborescence des fichiers en faisant glisser son bord, mais c’était impossible
    Je voulais voir le diff en plus grand, et comme les noms de fichiers étaient courts, la majeure partie de la zone de l’arborescence était gâchée ; il n’y avait pas non plus de touche indiquée dans l’aide H, donc il semble qu’on ne puisse pas non plus redimensionner au clavier
    Même si c’était possible au clavier, dans ce genre de cas le redimensionnement à la souris est bien plus simple et rapide, et ce serait bien d’avoir aussi un réglage au clavier pour les environnements SSH cassés où la souris n’est pas utilisable

    • Compléter les raccourcis clavier avec la prise en charge de la souris dans le terminal est vraiment utile
      Même dans Vim, j’utilise encore le trackpad/la souris pour faire défiler et redimensionner les fenêtres, et il n’y a pas de raison de ne pas proposer les deux, même via SSH
      Ce serait aussi un bon ajout ici

  • Il est indiqué que lazygit a inspiré ce projet, mais en tant qu’utilisateur de lazygit, je me demande ce qui manquait pour justifier un tout nouveau projet
    J’utilise lazygit avec beaucoup d’efficacité

    • Je ne sais pas si la méthodologie tient vraiment la route, mais vu avec un œil de manager, les chiffres sont assez impressionnants
      Pour une présentation au meetup RustBerlin, ils ont parsé l’intégralité du dépôt Git du noyau Linux pour comparer lazygit, tig et gitui, et ce dépôt contenait plus de 900 000 commits
      gitui prenait 24 secondes, 0,17 Go de mémoire, un binaire de 1,4 Mo, aucun freeze, aucun crash ; lazygit prenait 57 secondes, 2,6 Go, 16 Mo, avec des freezes et des crashs occasionnels ; tig prenait 4 min 20 s, 1,3 Go, 0,6 Mo, avec quelques freezes mais aucun crash
    • J’utilise lazygit tous les jours depuis des années et j’ai aussi essayé celui-ci il y a quelques mois ; ça m’a surtout donné l’impression d’un cas où l’on réécrit en Rust un outil déjà presque parfait
      De mémoire, il n’avait aucune fonctionnalité absente de lazygit, et il lui manquait même certaines fonctions présentes dans lazygit
    • La motivation est décrite dans le README
      Ils font la plupart de leurs opérations Git dans le terminal, mais utilisent souvent un Git GUI pour l’index, commit, diff, stash, blame, log, etc., et selon eux les Git GUI populaires échouaient ou devenaient non réactifs sur des dépôts énormes

  • La phrase « les Git GUI populaires échouent ou deviennent non réactifs sur des dépôts énormes » ne me fait penser qu’aux cas où git status devient lent en ligne de commande ou dans magit à cause d’une arborescence de répertoires très profonde qui n’a pas encore été ajoutée au .gitignore
    Dans ce cas, je ne vois pas vraiment de différence entre utiliser Git en GUI, TUI ou ligne de commande
    D’autres interfaces Git échouent-elles plus spectaculairement que Git lui-même ?

    • À mon avis, la façon dont Magit échoue vient de sous-opérations qui vont chercher des informations de diff sur la page de status
      Même avec le même problème, git status en ligne de commande finissait presque immédiatement
      Quand on veut afficher beaucoup d’informations, il est inévitable que cela prenne du temps, mais magit a tendance à être trop eager à certains endroits et à créer des flux de travail bien plus coûteux que le flux Git brut
    • Je ne fais jamais de gros merges dans magit ; pour ça, j’utilise le Git CLI
    • Dans ce cas, c’est surprenant
      L’interface Git d’IntelliJ est écrite en Java et intégrée à l’IDE, et pourtant elle est suffisamment rapide ; une interface Git externe ne devrait donc pas poser problème

  • Articles liés :
    GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 - septembre 2022, 90 commentaires
    Terminal-UI for Git written in Rust - https://news.ycombinator.com/item?id=25504811 - décembre 2020, 1 commentaire

  • Quelqu’un a-t-il déjà créé une interface en cliquer-glisser pour Git ?
    Je parle d’une UI où l’on pourrait manipuler les branches simplement en les faisant glisser

    • Mon Git GUI préféré est Fork : https://git-fork.com/
      Il prend en charge le glisser-déposer pour diverses opérations comme merge, rebase, stage/unstage, et probablement d’autres encore
    • J’utilise GitHub Desktop pour les opérations de base et la CLI pour les choses complexes
      C’est un client Git assez simple, mais il propose un peu de glisser-déposer pour des opérations comme le cherry-pick de commits
    • J’ai déjà vu une extension qui mettait ça en avant comme argument marketing, mais je ne l’ai jamais essayée
      https://marketplace.visualstudio.com/items?itemName=trunkflo...
    • Même après 10 ans, quand j’ai besoin de cliquer-glisser dans une UI, je reviens encore surtout à SourceTree

  • J’essaie tous ces outils, mais il manque toujours une fonctionnalité essentielle ou bien ils ne se comportent pas comme je le voudrais, donc je finis toujours par revenir à tig
    Dans GitUI, je n’ai pas trouvé d’indicateur montrant clairement la structure des branches, par exemple dans la vue Log
    J’aimerais un outil qui montre bien la structure des branches pour réfléchir aux rebases

  • Ça a l’air bien, je pense l’essayer
    J’espère qu’un jour GitExtensions sera porté en application Linux native
    J’ai essayé des dizaines d’interfaces, mais rien n’arrive à sa hauteur

    • Depuis que je suis passé à Linux, la seule application Windows qui me manque chaque jour est TortoiseGit
      Je n’ai encore trouvé aucune interface Git qui rende un système basé sur le menu contextuel aussi naturel à utiliser que TortoiseGit
    • Je suis toujours surpris de voir si peu de développeurs connaître GitExtensions
      La seule autre interface Git comparable, c’est Tortoise, mais à l’époque je n’avais essayé que sa variante hg
    • Gitex est excellent
      J’utilise encore la version mono 2.x sur Linux

  • Cela ressemble beaucoup au plugin Neovim neogit, que j’ai commencé à utiliser il y a environ un mois
    Les raccourcis clavier étaient un peu rugueux, et il m’a fallu environ une heure pour vraiment m’habituer au flux de travail complet, mais une fois habitué c’était bien plus rapide que mon ancienne méthode qui consistait à suspendre neovim pour utiliser Git directement dans le shell
    0: https://github.com/NeogitOrg/neogit

  • L’une des choses qui m’inquiètent avec les outils UI, c’est qu’ils cachent souvent les vraies commandes à l’utilisateur, ce qui rend ensuite plus difficile de comprendre ce qui s’est mal passé et comment l’éviter à l’avenir
    Par exemple, certains outils peuvent ajouter des flags assez prescriptifs qui ne correspondent pas au flux CLI habituel
    Je ne sais pas si c’est le cas pour cet outil, mais c’est peut-être un retour intéressant pour cette catégorie d’outils

    • C’est pour ça que j’utilise et apprécie GitExtensions sous Windows
      Il affiche toujours l’intégralité des commandes qu’il exécute, et on peut aussi consulter complètement tout le journal