Noticias técnicas sobre GitUI

 (github.com/extrawurst)
10 puntos por GN⁺ 2024-01-08 | 1 comentarios | Compartir por WhatsApp
  • GitUI es una herramienta que ofrece la usabilidad y comodidad de una GUI de Git dentro de la terminal, y surgió a partir de casos de uso donde las GUI de Git existentes se congelaban o se volvían lentas en repositorios enormes.
  • Sus funciones principales incluyen uso solo con teclado, ayuda contextual, inspección de cambios, commit y amend, stage/unstage/revert/reset por archivo, hunk o línea, stash, push/fetch, gestión de ramas, búsqueda en el historial de commits y revisión de diffs.
  • En una comparación que parseó más de 900 mil commits del repositorio Git de Linux, gitui registró 24 segundos y 0.17 GB de memoria, mientras que lazygit registró 57 segundos y 2.6 GB, y tig 4 minutos 20 segundos y 1.3 GB.
  • Entre los objetivos previos a la versión 1.0 están la visualización de la estructura de ramas en la pestaña de logs y interactive rebase; existen limitaciones conocidas en git-lfs, sparse repos y el manejo automático de credential.helper para HTTPS.
  • Actualmente no reemplaza por completo la shell de Git; más bien es una herramienta para usar junto con ella, complementando tareas incómodas en la shell de Git, como stash o staging por línea y hunk.

Una herramienta que lleva la experiencia de una GUI de Git a la terminal

  • GitUI es una herramienta open source que ofrece la experiencia de usuario y la comodidad de una GUI de Git en la terminal.
  • La motivación de desarrollo surgió de la experiencia de hacer la mayoría de las tareas de Git en la terminal, pero aun así recurrir con frecuencia a una GUI de Git para tareas como index, commit, diff, stash, blame y log.
  • Las GUI de Git populares existentes tenían problemas en repositorios enormes: fallaban, dejaban de responder o se volvían inutilizables.
  • GitUI apunta a ofrecer una experiencia de GUI de Git dentro de la terminal que sea portable, fast, free y opensource.

Alcance de funciones

  • El modelo de uso se centra en control solo con teclado y ayuda contextual, y está diseñado para no exigir memorizar muchos atajos.
  • El trabajo con cambios incluye lo siguiente:
    • Inspect de cambios, commit y amend
    • Hooks pre-commit, commit-msg, post-commit y prepare-commit-msg
    • Stage, unstage, revert y reset por archivo, hunk o línea
  • También admite tareas del flujo del repositorio:
    • Guardar, pop, apply, drop e inspect de stash
    • Push a un remote y fetch desde un remote
    • Crear, renombrar, eliminar y hacer checkout de ramas, y ver remotes
    • Navegación y búsqueda en el historial de commits, y revisión de diffs de cambios commiteados
  • La UI y el funcionamiento interno incluyen una UI de terminal responsiva, una API de Git asíncrona para una interacción fluida y soporte para submodules.
  • GPG commit signing está soportado, pero tiene restricciones relacionadas con #97.

Resultados de benchmark

  • En una presentación del meetup RustBerlin se compararon lazygit, tig y gitui parseando todo el repositorio Git de Linux.
  • Los resultados de la comparación fueron los siguientes:
    • gitui: 24 segundos, 0.17 GB de memoria, binario de 10 MB, sin freeze, sin crash
    • lazygit: 57 segundos, 2.6 GB de memoria, binario de 25 MB, con freeze, crash ocasional
    • tig: 4 minutos 20 segundos, 1.3 GB de memoria, binario de 0.6 MB, freeze ocasional, sin crash
  • En esta comparación, gitui registró los valores más bajos en tiempo y memoria.

Roadmap previo a la versión 1.0 y limitaciones conocidas

  • Hay dos objetivos principales antes de llamarlo 1.0:
    • Visualización de la estructura de ramas en la pestaña de logs: #81
    • Interactive rebase: #32
  • Las limitaciones actuales incluyen lo siguiente:
    • Sin soporte para git-lfs: #2812
    • Sin soporte para sparse repos: #1226
    • En HTTPS, credential.helper debe configurarse explícitamente: #800
  • Actualmente, GitUI no reemplaza por completo la shell de Git, y funciona bien usar ambas herramientas juntas.
  • La prioridad está puesta en funciones que resultan incómodas en la shell de Git, como stash y staging por línea o hunk.
  • El proyecto actualmente es un spare time project, y se necesita ayuda para convertir GitUI en una one stop solution.

Instalación y compilación

  • GitUI está en estado beta, por lo que puede tener bugs y funciones faltantes.
  • Es razonablemente estable para uso personal y también se usa para desarrollar el propio GitUI.
  • Se puede instalar con varios package managers:
    • 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
  • Los binarios de release están disponibles para Linux, macOS y Windows.
    • Linux cuenta con paquetes para x86_64, aarch64, arm y armv7.
    • macOS cuenta con paquetes para arm64 e Intel x86.
    • Windows cuenta con un binario único de 64 bits y un paquete de instalación MSI de 64 bits.
  • Los requisitos de compilación son los siguientes:
    • La versión mínima soportada de rust/cargo es 1.88.
    • Para compilar la dependencia de OpenSSL se requiere perl 5.12 o superior y un compilador de C.
    • Para ejecutar toda la suite de pruebas se necesita Python invocable como python.
  • Con Cargo se puede iniciar la compilación e instalación con el comando cargo install gitui --locked.
  • La Cargo feature trace-libgit activa el tracing de libgit2, y funciona si libgit2 fue compilado con -DENABLE_TRACE=ON.
  • Esta feature viene activada por defecto; para desactivarla, usa cargo install --no-default-features.

Configuración, diagnóstico y personalización

  • El logging se activa con gitui -l.
  • La ubicación del archivo de logs varía según la plataforma:
    • 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 debería funcionar automáticamente tanto con temas de terminal light como dark.
  • Los temas de color se pueden personalizar a gusto siguiendo THEMES.md.
  • Los key bindings se pueden personalizar siguiendo KEY_CONFIG.md, y pueden configurarse con bindings estilo vim.
  • Los proyectos citados como inspiración son lazygit, tig, GitUp y git-brunch.
  • Sobre GitUp, se agrega el objetivo de encontrar una forma de usar una map view en una herramienta de terminal.

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-08
Opiniones en Hacker News

  • Apenas lo instalé, la ventana de xterm era demasiado chica, así que la agrandé; intenté reducir el área del árbol de archivos arrastrando el borde, pero no se pudo.
    Quería ver el diff más grande y los nombres de archivo eran cortos, así que la mayor parte del área del árbol se desperdiciaba. En la ayuda con H tampoco había una tecla relacionada, así que parece que tampoco se puede ajustar el tamaño con el teclado.
    Incluso si fuera posible con el teclado, en estos casos redimensionar con el mouse es mucho más fácil y rápido, y estaría bueno que también hubiera ajuste con teclado para cuando no se puede usar el mouse, como en entornos SSH rotos.

    • Complementar los atajos de teclado con soporte de mouse en la terminal es realmente útil.
      Incluso en Vim, las partes donde sigo usando trackpad/mouse son el scroll y el cambio de tamaño de ventanas, y no hay razón para no ofrecer ambas cosas también a través de SSH.
      Creo que también sería una buena incorporación aquí.

  • lazygit aparece como inspiración de este proyecto; como usuario de lazygit, me da curiosidad saber qué le faltaba como para necesitar un proyecto completamente nuevo.
    Uso lazygit y me resulta muy útil.

    • Es difícil juzgar si la metodología es válida, pero vistos con ojos de manager, los números son bastante impresionantes.
      Para una presentación del meetup RustBerlin, parsearon todo el repositorio Git de Linux para comparar lazygit, tig y gitui, y el repositorio tenía más de 900.000 commits.
      gitui tardó 24 segundos, usó 0,17 GB de memoria, binario de 1,4 MB, sin congelarse ni crashear; lazygit tardó 57 segundos, 2,6 GB, 16 MB, con congelamientos y crasheos ocasionales; y tig tardó 4 min 20 s, 1,3 GB, 0,6 MB, con congelamientos ocasionales y sin crasheos.
    • Uso lazygit todos los días desde hace años y probé esto también hace unos meses; me pareció un caso de crear algo para reescribir en Rust una herramienta casi perfecta.
      Según recuerdo, no tenía ninguna función que no existiera en lazygit; más bien le faltaban algunas funciones que sí tiene lazygit.
    • La motivación está en el README.
      Dice que la mayoría de las tareas de Git las hacen en la terminal, pero que para index, commit, diff, stash, blame y log terminaban usando con frecuencia una GUI de Git, y que las GUI populares de Git fallaban o dejaban de responder en repositorios enormes, por lo que no se podían usar.

  • Eso de que “las GUI populares de Git fallan o dejan de responder en repositorios enormes” solo lo he visto cuando git status tarda mucho en la línea de comandos o en magit por un árbol de directorios muy profundo que todavía no se agregó a .gitignore.
    En esos casos no veo diferencia entre usar Git desde una GUI, una TUI o la línea de comandos.
    ¿Otras interfaces de Git fallan de forma más dramática que el propio Git?

    • Creo que el modo de falla de Magit se debe a suboperaciones que traen información de diff en la página de status.
      Incluso con el mismo problema, en la línea de comandos git status terminaba casi al instante.
      Es inevitable que mostrar mucha información requiera tiempo, pero magit en algunos puntos actúa de forma demasiado eager y a veces crea un flujo de trabajo mucho más costoso que el flujo de Git en bruto.
    • Nunca hago merges grandes en magit; para eso uso la CLI de Git.
    • Entonces me sorprende.
      La UI de Git de IntelliJ está escrita en Java e incluida dentro del IDE, y aun así es lo suficientemente rápida, así que una UI externa de Git no debería tener problemas.

  • Artículos relacionados:
    GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 - septiembre de 2022, 90 comentarios
    Terminal-UI for Git written in Rust - https://news.ycombinator.com/item?id=25504811 - diciembre de 2020, 1 comentario

  • ¿Alguien ha creado una UI de clic y arrastrar para Git?
    Me refiero a una UI en la que puedas trabajar simplemente arrastrando y soltando ramas.

    • Mi GUI de Git favorita es Fork: https://git-fork.com/
      Soporta arrastrar y soltar para varias operaciones como merge, rebase y stage/unstage, y probablemente para más cosas.
    • Uso GitHub Desktop para tareas básicas y la CLI para lo complejo.
      Es un cliente Git bastante simple, pero tiene algo de funcionalidad de arrastrar para operaciones como cherry-pick de commits.
    • Vi una extensión que promocionaba eso como una de sus funciones, pero no la probé.
      https://marketplace.visualstudio.com/items?itemName=trunkflo...
    • Incluso después de 10 años, cuando necesito clic y arrastre en una UI, todavía suelo usar SourceTree.

  • Pruebo todas estas herramientas, pero siempre les falta una función clave o no se comportan como quiero, así que al final vuelvo a tig.
    En GitUI no pude encontrar una visualización que muestre bien la estructura de ramas en lugares como la vista Log.
    Me gustaría una herramienta que muestre bien la estructura de ramas pensando en rebase.

  • Se ve bien, así que pienso probarlo.
    Espero que algún día GitExtensions se porte como aplicación nativa de Linux.
    He probado decenas de UIs y parece que no hay nada a su nivel.

    • La única app de Windows que extraño todos los días desde que me pasé a Linux es TortoiseGit.
      Todavía no ha habido una UI de Git que haga que un sistema basado en menús contextuales se sienta tan natural como TortoiseGit.
    • Siempre me sorprende que tan pocos desarrolladores conozcan GitExtensions.
      La única otra UI de Git que se le acerca es Tortoise, aunque antes solo probé la variante para hg.
    • Gitex es excelente.
      En Linux todavía uso la versión 2.x con mono.

  • Se parece mucho a neogit, un plugin de Neovim que empecé a usar hace aproximadamente un mes.
    Los keybindings eran un poco toscos y me tomó alrededor de una hora acostumbrarme de verdad al flujo completo, pero después de acostumbrarme se volvió mucho más rápido que mi método anterior: suspender neovim y usar Git directamente en la shell.
    0: https://github.com/NeogitOrg/neogit

  • Una de las cosas que me preocupan de las herramientas con UI es que muchas veces le ocultan al usuario los comandos reales, lo que luego dificulta razonar qué salió mal y cómo evitarlo en el futuro.
    Por ejemplo, algunas herramientas pueden agregar flags bastante opinados que no encajan con el flujo normal de la CLI.
    No sé si esto aplica a esta herramienta, pero podría ser feedback interesante para herramientas de esta categoría.

    • Por eso en Windows uso GitExtensions y me gusta.
      Siempre muestra el comando completo que ejecuta, y también se puede ver el log completo.