DiffsHub

 (diffshub.com)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Quando é preciso revisar rapidamente um diff grande do GitHub no navegador, o DiffsHub é uma ferramenta que mostra diffs públicos em uma interface virtualizada
  • Basta trocar github.com por diffshub.com na URL do GitHub para ver imediatamente alterações de PR, comparação, commit, diff e patch
  • Sem exigir nenhum processo extra de conversão, ele mantém a estrutura original da URL, permitindo acessar github.com/org/repo/pull/number como diffshub.com/org/repo/pull/number
  • Ele consegue lidar até com comparações de milhões de linhas, como no Linux v6.0...v7.0, embora navegadores mobile possam ocasionalmente travar
  • O GitHub pode atrasar a resposta do primeiro byte e não entregar diffs com mais de 100k linhas de forma estável, então pode ser uma alternativa para revisar mudanças grandes

Visualizador de diff que usa a URL do GitHub diretamente

  • DiffsHub é uma ferramenta para ver diffs públicos do GitHub de forma rápida em uma interface virtualizada e agradável de navegar
  • Suporta PR, comparação, commit, diff e patch
  • O usuário acessa apenas trocando o domínio na URL do GitHub
    • github.com/org/repo/pull/number
    • diffshub.com/org/repo/pull/number

Diffs com milhões de linhas e limitações

  • O DiffsHub consegue lidar com comparações na escala de milhões de linhas
  • Como exemplo, é possível ver a comparação Linux v6.0...v7.0
  • Comparações grandes assim podem ocasionalmente travar em navegadores mobile
  • O GitHub pode fornecer de forma instável diffs com mais de 100k linhas, com atraso na resposta do primeiro byte

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Opiniões no Lobste.rs

  • Tentei entender o que visualizar diffs tem a ver com a tag vibecoding
    Depois peguei o contexto e o drama, e entendi por que isso aconteceu. Desculpas ao @quad por ter gerado ruído, e agora vi que a tag já foi removida

    • O Lobsters entrou numa fase meio estranha, em que as pessoas estão decidindo arbitrariamente se um projeto “parece ter sido vibecoded”
      Por exemplo, colocam a tag vibecoding por motivos como baixa qualidade de código, poucos commits, ou até só porque existe um CLAUDE.md no repositório, o que parece não significar muita coisa
    • Havia um CLAUDE.md no repositório. Aqui ele foi removido por engano, e acho que nesta postagem a tag era apropriada
    • Felizmente, essa tag agora parece ter sumido

  • Como contexto adicional, este texto parece relevante: On Rendering Diffs
    Até ao navegar pelo diff do Linux linkado na página inicial, a experiência foi bem fluida e impressionante. Dá para perceber isso arrastando a barra de rolagem manualmente. Seria ótimo se o GitHub, outros editores de diff no navegador, e até o Graphite que uso no trabalho fossem tão fluidos assim
    Por outro lado, é estranho até ficar impressionado com isso. Dá a sensação de que esse deveria ser o padrão

    • Conheço uma das pessoas que fez a maior parte do trabalho de renderização de diff e também o autor desse texto. Recebi atualizações em tempo real por mensagem durante o processo, e foi realmente impressionante ver quanta pesquisa e trabalho foram investidos nisso
      Literalmente foram meses de trabalho em tempo integral para fazer a renderização de diffs ficar rápida
      A propósito, embora tenha recebido a tag “vibecoding”, eu ainda não entendo isso, porque esse trabalho não teve nada desse tipo. A maior parte foi pesquisa difícil, leitura de código de implementação de navegador, tentativa e erro, e investigação séria dos problemas
      Loops com agentes foram usados em tarefas exploratórias muito específicas e com retorno claro, mas pelo que sei nada entrou sem insight e revisão humana. O texto do blog também parece abordar isso, e essa parte foi realmente pequena no trabalho como um todo. Desmerecer esse esforço de engenharia por causa disso não faz sentido
      Recomendo fortemente ler o texto do blog ou olhar o código. É um trabalho impressionante e há muito a aprender
    • Realmente, isso deveria ser o padrão. Queria que o GitLab e o Forgejo também adotassem isso
      Fiz um bookmarklet para testar diretamente: 
      javascript:(function(){window.open(window.location.href.replace('github.com','diffshub.com'),'_blank');})();
      Infelizmente, muitos PRs, especialmente os grandes, precisam de recurso de comentários. Vai ser interessante ver quando o Pierre vai avançar até essa área e talvez criar algo como https://www.reviewable.io/

  • O npmjs diz que é Apache 2, mas não há licença no repositório e no package.json ainda consta "private":true, então foi difícil entender o motivo
    A resposta parece ser que cada diretório é licenciado separadamente: https://github.com/pierrecomputer/pierre/…
    E o próprio diffshub aparentemente não está incluído na parte open source: https://github.com/pierrecomputer/pierre/…
    Esse modelo de licenciamento cirúrgico deixa diretórios como https://github.com/pierrecomputer/pierre/… numa situação ambígua. Isso porque esse diretório não tem um LICENCE.md Apache 2, embora a história possa ser diferente se considerarmos o campo package.json como autoridade

  • A UI parece melhor que a do GitHub, exceto pelo contraste. Não sei dizer quanto à acessibilidade

  • Só para constar, em qualquer pull request do GitHub dá para obter o diff adicionando .diff no final
    Exemplo: https://github.com/oven-sh/bun/pull/30412.diff
    Se adicionar .patch, também dá para obter um formato que pode ser enviado ao git am: https://github.com/oven-sh/bun/pull/30412.patch

    • error: too big or took too long to generate
      Escolheram esse PR de propósito por causa disso? :D

  • Talvez eu tenha expectativas mais baixas do que outras pessoas em relação a ferramentas, mas ao comparar isso com a funcionalidade nativa do GitHub, não consigo ver bem uma diferença prática
    Todo mundo fica lamentando como o GitHub é ruim, mas eu nunca tive essa mesma experiência. Não entendo por que eu deveria usar isso em vez do GitHub

    • Gravei um vídeo mostrando por que isso é importante para mim. Desculpem por estar no X, mas foi onde publiquei
      Historicamente, essa tem sido minha experiência comum, e também explico por que velocidade importa. Quando alguma tarefa fica lenta por tempo suficiente, meus pensamentos começam a vagar, e isso prejudica bastante meu estado de fluxo
      O vídeo compara lado a lado o tempo para abrir um PR e navegar até um arquivo específico. Para mim, isso é uma tarefa cotidiana bem comum
      https://x.com/mitchellh/status/2057229385963618787

  • Parece bem parecido com pulldash(feito pela coder.com) ou difit(uma CLI que sobe uma página em localhost)
    Não gosto muito de nenhum dos dois. O pulldash era meio travado e o difit exigia esforço extra. Para self-review, hoje uso a extensão do VSCode git tree compare
    Ela é rápida e eu também gosto do visual geral. Testei com um dos meus PRs e pareceu suficientemente boa; talvez eu até deixe isso salvo nos favoritos no PC