Novidades técnicas sobre o GitUI

 (github.com/extrawurst)
10 pontos por GN⁺ 2024-01-08 | 1 comentários | Compartilhar no WhatsApp
  • GitUI é uma ferramenta que oferece, dentro do terminal, a usabilidade e a conveniência de uma GUI de Git, surgida a partir de casos de uso em que GUIs de Git existentes travavam ou ficavam lentas em repositórios gigantes
  • Os principais recursos incluem operação totalmente por teclado, ajuda contextual, inspeção de mudanças, commit e amend, stage/unstage/revert/reset em nível de arquivo, hunk e linha, stash, push/fetch, gerenciamento de branches, busca no log de commits e visualização de diff
  • Em uma comparação analisando mais de 900 mil commits do repositório Git do Linux, gitui registrou 24 segundos e 0,17GB de memória, enquanto lazygit marcou 57 segundos e 2,6GB, e tig 4 minutos e 20 segundos e 1,3GB
  • Antes da versão 1.0, as metas incluem visualização da estrutura de branches na aba de log e interactive rebase, e há limitações conhecidas no tratamento automático de credential.helper para HTTPS, além de ausência de suporte a git-lfs e sparse repo
  • No momento, ele não substitui completamente o Git shell e funciona mais como uma ferramenta complementar para tarefas incômodas no shell, como stash ou staging por linha e por hunk

Uma ferramenta que leva a experiência de Git GUI para o terminal

  • GitUI é uma ferramenta open source que oferece no terminal a experiência de usuário e a conveniência de uma Git GUI
  • A motivação de desenvolvimento veio da experiência de fazer a maior parte do trabalho com Git no terminal, mas ainda recorrer com frequência a uma Git GUI para tarefas como index, commit, diff, stash, blame e log
  • GUIs de Git populares já existentes apresentavam problemas em repositórios gigantes, falhando, deixando de responder ou se tornando inutilizáveis
  • O objetivo do GitUI é oferecer, dentro do terminal, uma experiência de Git GUI portable, fast, free e opensource

Escopo de recursos

  • O modelo de operação é centrado em controle apenas por teclado e ajuda contextual, com design pensado para evitar a necessidade de decorar muitos atalhos
  • As operações sobre mudanças incluem:
    • inspecionar mudanças, commit, amend
    • suporte aos hooks pre-commit, commit-msg, post-commit, prepare-commit-msg
    • stage, unstage, revert e reset em nível de arquivo, hunk e linha
  • Também há suporte ao fluxo de trabalho do repositório:
    • salvar, pop, apply, drop e inspecionar stash
    • push para remotes e fetch a partir de remotes
    • criar, renomear, excluir e fazer checkout de branches, além de visualizar remotes
    • navegar pelo log de commits, buscar e verificar o diff de mudanças já commitadas
  • A UI e o funcionamento interno incluem UI de terminal responsiva, API Git assíncrona para operação fluida e suporte a submodules
  • Há suporte a GPG commit signing, mas com limitações relacionadas à #97

Resultados de benchmark

  • Em uma apresentação no RustBerlin meetup, lazygit, tig e gitui foram comparados analisando todo o repositório Git do Linux
  • Os resultados da comparação foram os seguintes:
    • gitui: 24 segundos, 0,17GB de memória, binário de 10MB, sem freeze, sem crash
    • lazygit: 57 segundos, 2,6GB de memória, binário de 25MB, com freeze, crash ocasional
    • tig: 4 minutos e 20 segundos, 1,3GB de memória, binário de 0,6MB, freeze ocasional, sem crash
  • Nessa comparação, o gitui registrou os menores valores em tempo e uso de memória

Roadmap antes da 1.0 e limitações conhecidas

  • Antes de ser chamado de 1.0, há duas metas principais:
    • visualização da estrutura de branches na aba de log: #81
    • interactive rebase: #32
  • As limitações atuais incluem:
    • sem suporte a git-lfs: #2812
    • sem suporte a sparse repo: #1226
    • em HTTPS, é necessário configurar credential.helper explicitamente: #800
  • No momento, o GitUI não substitui completamente o Git shell, e o uso combinado das duas ferramentas funciona bem
  • A prioridade está em recursos desconfortáveis no Git shell, como stash e staging por linha e por hunk
  • O projeto atualmente é um spare time project, e precisa de ajuda para transformar o GitUI em uma one stop solution

Instalação e build

  • O GitUI está em estado beta e pode ter bugs e recursos ausentes
  • Para uso pessoal, ele é razoavelmente estável e já é usado no próprio desenvolvimento do GitUI
  • Pode ser instalado com vários gerenciadores de pacotes:
    • 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
  • Binários de release são oferecidos para Linux, macOS e Windows
    • No Linux, há pacotes para x86_64, aarch64, arm e armv7
    • No macOS, há pacotes para arm64 e Intel x86
    • No Windows, há um binário único de 64bit e um pacote instalador MSI de 64bit
  • Os requisitos para build são os seguintes:
    • a versão mínima suportada de rust/cargo é 1.88
    • para buildar a dependência OpenSSL, são necessários perl 5.12 ou superior e um compilador C
    • para executar toda a suíte de testes, é necessário um Python que possa ser chamado como python
  • Com Cargo, o build e a instalação podem ser iniciados com o comando cargo install gitui --locked
  • A feature de Cargo trace-libgit ativa o tracing de libgit2 e funciona quando libgit2 foi buildado com -DENABLE_TRACE=ON
  • Essa feature vem ativada por padrão, e pode ser desativada com cargo install --no-default-features

Configuração, diagnóstico e customização

  • O logging é ativado com gitui -l
  • A localização do arquivo de log varia por plataforma:
    • macOS: $HOME/Library/Caches/gitui/gitui.log
    • Linux com XDG: $XDG_CACHE_HOME/gitui/gitui.log
    • Linux: $HOME/.cache/gitui/gitui.log
    • Windows: %LOCALAPPDATA%/gitui/gitui.log
  • O GitUI deve funcionar automaticamente tanto com temas claros quanto escuros de terminal
  • O tema de cores pode ser customizado como quiser, seguindo THEMES.md
  • Os atalhos de teclado podem ser customizados conforme KEY_CONFIG.md, inclusive com bindings no estilo vim
  • Os projetos citados como inspiração são lazygit, tig, GitUp e git-brunch
  • Sobre o GitUp, há também a meta adicional de encontrar uma forma de usar uma map view em uma ferramenta de terminal

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-08
Opiniões no Hacker News

  • Assim que instalei, a janela do xterm estava pequena demais, então aumentei; tentei reduzir a área da árvore de arquivos arrastando sua borda, mas não dava
    Eu queria ver o diff maior, e os nomes de arquivo também eram curtos, então a maior parte da área da árvore era desperdiçada; no help H também não havia nenhuma tecla relacionada, então parece que nem pelo teclado dá para redimensionar
    Mesmo que desse pelo teclado, nesse caso redimensionar com o mouse é muito mais fácil e rápido, e seria bom ter também ajuste pelo teclado para quando não for possível usar o mouse, como em um ambiente SSH quebrado

    • Complementar os atalhos de teclado com suporte a mouse no terminal é realmente útil
      Mesmo no Vim, as partes em que ainda uso trackpad/mouse são rolagem e redimensionamento de janelas, e não há motivo para não oferecer ambos também via SSH
      Parece que seria um bom recurso adicional aqui

  • O lazygit aparece como inspiração para este projeto, e, como usuário do lazygit, fico curioso sobre o que faltava a ponto de ser necessário um projeto totalmente novo
    Uso o lazygit com muita utilidade

    • É difícil julgar se a metodologia é válida, mas, aos olhos de um gerente, os números são bem impressionantes
      Para uma apresentação no meetup RustBerlin, foi feito o parsing de todo o repositório Git do Linux para comparar lazygit, tig e gitui, e o repositório tinha mais de 900 mil commits
      O gitui levou 24 segundos, usou 0,17 GB de memória, binário de 1,4 MB, sem travamentos, sem crashes; o lazygit levou 57 segundos, 2,6 GB, 16 MB, com travamentos, crashes ocasionais; e o tig levou 4 min 20 s, 1,3 GB, 0,6 MB, travamentos ocasionais, sem crashes
    • Uso o lazygit diariamente há anos e testei isto alguns meses atrás; pareceu um caso criado para reescrever em Rust uma ferramenta quase perfeita
      Pelo que lembro, não havia nenhum recurso que não existisse no lazygit e, pelo contrário, faltavam alguns recursos que o lazygit tem
    • A motivação está no README
      A maioria das operações Git é feita no terminal, mas para usos como index, commit, diff, stash, blame e log, a pessoa passou a usar com frequência uma GUI para Git; e as GUIs populares de Git falhavam em repositórios enormes ou ficavam sem resposta, tornando-se inutilizáveis

  • A afirmação de que “GUIs populares de Git falham em repositórios enormes ou ficam sem resposta e não podem ser usadas” eu só vi quando o git status demora na linha de comando ou no magit por causa de uma árvore de diretórios muito profunda que ainda não foi colocada no .gitignore
    Nesses casos, não vejo diferença entre usar Git por GUI/TUI/linha de comando
    Outras interfaces Git falham de forma mais dramática do que o próprio Git?

    • Acho que o modo de falha do Magit vem de operações secundárias que puxam informações de diff na página de status
      Mesmo com o mesmo problema, git status na linha de comando terminava quase imediatamente
      É inevitável que exibir muita informação leve tempo, mas o magit às vezes age de forma eager demais em certos pontos e cria fluxos de trabalho muito mais caros que o fluxo Git bruto
    • Nunca faço merges grandes no magit; para isso uso a CLI do Git
    • Então é surpreendente
      A UI de Git do IntelliJ é escrita em Java e fica dentro da IDE, mas ainda assim é rápida o suficiente, então uma UI Git externa não deveria ter problema

  • Posts relacionados:
    GitUI: Terminal UI for Git - https://news.ycombinator.com/item?id=32864036 - setembro de 2022, 90 comentários
    Terminal-UI for Git written in Rust - https://news.ycombinator.com/item?id=25504811 - dezembro de 2020, 1 comentário

  • Alguém já criou uma UI de clicar e arrastar para Git?
    Uma UI em que dê para trabalhar simplesmente arrastando branches, por exemplo

    • Minha GUI de Git favorita é o Fork: https://git-fork.com/
      Ele oferece arrastar e soltar para várias operações, como merge, rebase, stage/unstage, e provavelmente outras
    • Uso o GitHub Desktop para tarefas básicas e a CLI para coisas complexas
      É um cliente Git bem simples, mas tem um pouco de funcionalidade de arrastar para operações como cherry-pick de commits
    • Já vi uma extensão que anunciava isso como um dos recursos, mas não cheguei a usar
      https://marketplace.visualstudio.com/items?itemName=trunkflo...
    • Mesmo depois de 10 anos, quando preciso clicar e arrastar na UI, ainda uso principalmente o SourceTree

  • Testo todas essas ferramentas, mas sempre falta uma função essencial ou algo não funciona do jeito que eu quero, então acabo voltando para o tig
    No GitUI, não consegui encontrar uma visualização que mostrasse bem a estrutura de branches em lugares como a view de Log
    Seria bom ter uma ferramenta que mostrasse bem a estrutura de branches pensando em rebase

  • Parece bom, então pretendo testar
    Espero que um dia o GitExtensions seja portado como uma aplicação nativa para Linux
    Já usei dezenas de UIs, mas parece não haver nada à altura

    • O único app de Windows de que sinto falta todos os dias depois de migrar para Linux é o TortoiseGit
      Ainda não houve uma UI de Git que me fizesse usar um sistema baseado em menu de contexto de forma tão natural quanto o TortoiseGit
    • Sempre me surpreende que tão poucos desenvolvedores conheçam o GitExtensions
      A única outra UI de Git próxima dele é o Tortoise, embora eu só tenha usado sua variante para hg no passado
    • O Gitex é excelente
      No Linux, ainda uso a versão 2.x em mono

  • Parece muito parecido com o plugin de Neovim neogit, que comecei a usar há cerca de um mês
    Os key bindings eram um pouco ásperos e levei cerca de uma hora para realmente me acostumar ao fluxo de trabalho inteiro, mas, depois que me acostumei, ficou muito mais rápido do que meu método anterior de suspender o neovim e usar Git diretamente no shell
    0: https://github.com/NeogitOrg/neogit

  • Uma das minhas preocupações com ferramentas de UI é que muitas vezes elas escondem os comandos reais do usuário, o que dificulta depois deduzir o que deu errado e como evitar no futuro
    Por exemplo, uma ferramenta pode adicionar flags bastante opinativas que não combinam com o fluxo normal da CLI
    Não sei se isso se aplica a esta ferramenta, mas pode ser um feedback interessante para ferramentas dessa categoria

    • Por isso uso e gosto do GitExtensions no Windows
      Ele sempre mostra o comando completo que está executando, e também dá para ver o log inteiro por completo