DiffsHub

 (diffshub.com)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Lorsque vous devez parcourir rapidement un grand diff GitHub dans le navigateur, DiffsHub est un outil qui affiche les diffs publics dans une interface virtualisée
  • En remplaçant github.com par diffshub.com dans l’URL GitHub, vous pouvez voir directement les changements d’une PR, d’une comparaison, d’un commit, d’un diff ou d’un patch
  • Sans procédure de conversion supplémentaire, l’outil conserve la structure d’URL existante, ce qui permet par exemple de transformer github.com/org/repo/pull/number en diffshub.com/org/repo/pull/number
  • Il peut gérer des comparaisons de plusieurs millions de lignes comme Linux v6.0...v7.0, mais le navigateur mobile peut parfois planter
  • GitHub peut retarder le premier octet de réponse et ne pas fournir de manière fiable les diffs de plus de 100k lignes, ce qui en fait une alternative possible pour examiner de gros changements

Un visualiseur de diff qui conserve l’URL GitHub

  • DiffsHub est un outil permettant de consulter les diffs GitHub publics dans une interface virtualisée, rapide et agréable à lire
  • Sont pris en charge les PR, comparaisons, commits, diffs et patchs
  • L’utilisateur y accède simplement en changeant le domaine dans l’URL GitHub
    • github.com/org/repo/pull/number
    • diffshub.com/org/repo/pull/number

Diffs de plusieurs millions de lignes et limites

  • DiffsHub peut gérer des comparaisons à l’échelle de plusieurs millions de lignes
  • On peut par exemple consulter la comparaison Linux v6.0...v7.0
  • Ce type de comparaison volumineuse peut parfois faire planter les navigateurs mobiles
  • GitHub peut fournir de manière instable les diffs de plus de 100k lignes, avec un premier octet retardé

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Lobste.rs

  • J’essayais de comprendre le lien entre l’affichage des diff et le tag vibecoding
    Puis j’ai rattrapé le contexte et le drama pour comprendre pourquoi on en était arrivé là. Désolé auprès de @quad d’avoir ajouté du bruit, et je vois que le tag a maintenant été retiré

    • Lobsters est entré dans une phase un peu étrange où les gens décident arbitrairement si un projet « a l’air vibecoded » ou non
      Par exemple, ils collent le tag vibecoding pour une qualité de code jugée faible, un petit nombre de commits, ou même simplement parce qu’il y a un CLAUDE.md dans le dépôt, ce qui ne semble pas vouloir dire grand-chose
    • Il y avait un CLAUDE.md dans le dépôt. Ici, il a été retiré à tort, et je pense que c’était un tag approprié pour ce post
    • Heureusement, ce tag semble avoir disparu maintenant

  • Pour plus de contexte, ce billet semble pertinent : On Rendering Diffs
    C’est aussi assez impressionnant de parcourir les diff Linux liés sur la page d’accueil tellement c’est fluide. Il suffit d’essayer de faire glisser directement la barre de défilement pour s’en rendre compte. J’aimerais que Github, les autres éditeurs de diff dans le navigateur, et Graphite qu’on utilise au travail soient aussi fluides
    En même temps, c’est étrange d’être impressionné par ce genre de chose. On pourrait penser que ça devrait être la norme

    • Je connais la personne qui a fait l’essentiel du travail de rendu des diff, ainsi que l’auteur de ce billet. J’ai reçu des mises à jour en direct par SMS pendant le développement, et c’était vraiment impressionnant de voir la quantité de recherche et de travail investie
      Littéralement, plusieurs mois de travail à temps plein ont été consacrés à rendre les diff rapidement
      Au passage, même si le tag « vibecoding » a été appliqué, je ne comprends toujours pas pourquoi, et ce travail n’avait rien à voir avec ça. C’était surtout de la recherche difficile, de la lecture de code d’implémentation de navigateurs, des essais-erreurs, et une analyse méthodique du problème
      Des boucles d’agents ont bien été utilisées pour certaines tâches d’exploration très ciblées avec une récompense claire, mais à ma connaissance rien n’a été intégré sans l’intuition et la revue d’un humain. Le billet de blog semble aussi en parler, et cela représentait une part vraiment minime de l’ensemble du travail. Déprécier cet effort d’ingénierie pour cette seule raison n’a aucun sens
      Je recommande fortement de lire le billet de blog ou d’aller voir le code. C’est un travail remarquable, et on peut y apprendre beaucoup
    • Vraiment, ça devrait être la norme. J’aimerais que Gitlab et Forgejo adoptent ça aussi
      J’ai créé un bookmarklet pour le tester directement : 
      javascript:(function(){window.open(window.location.href.replace('github.com','diffshub.com'),'_blank');})();
      Malheureusement, beaucoup de PR, surtout les grosses, ont besoin de fonctionnalités de commentaires. Il faudra voir quand Pierre ira jusque-là et fera par exemple quelque chose comme https://www.reviewable.io/

  • npmjs indique Apache 2, mais il n’y a pas de licence dans le dépôt, et il y a même "private":true dans le package.json, donc il était difficile de comprendre pourquoi
    La réponse semble être que chaque répertoire est sous licence séparément : https://github.com/pierrecomputer/pierre/…
    Et diffshub lui-même ne semble pas faire partie de la section open source : https://github.com/pierrecomputer/pierre/…
    Cette approche de licence chirurgicale laisse des répertoires comme https://github.com/pierrecomputer/pierre/… dans une zone ambiguë. C’est parce qu’il n’y a pas de fichier LICENCE.md Apache 2 dans ce répertoire, même si l’histoire peut changer si l’on considère le champ package.json comme faisant autorité

  • L’UI semble meilleure que celle de Github, sauf pour le contraste. Je ne sais pas pour l’accessibilité

  • À noter que pour toutes les pull requests Github, on peut récupérer le diff en ajoutant .diff à la fin
    Exemple : https://github.com/oven-sh/bun/pull/30412.diff
    En ajoutant .patch, on peut aussi obtenir un format transmissible à git am : https://github.com/oven-sh/bun/pull/30412.patch

    • error: too big or took too long to generate
      C’est pour ça que cette PR a été choisie exprès ? :D

  • Peut-être que j’ai des attentes plus basses que d’autres vis-à-vis des outils, mais quand je compare ça aux fonctionnalités natives de Github, j’ai du mal à voir une différence pratique
    Tout le monde se plaint de la médiocrité de Github, mais je n’ai pas eu la même expérience. Je ne vois pas pourquoi j’utiliserais ça plutôt que Github

    • J’ai enregistré une vidéo pour montrer pourquoi c’est important pour moi. Désolé qu’elle soit sur X, mais c’est là que je l’ai mise
      Historiquement, ça correspond à mon expérience habituelle, et ça explique aussi pourquoi la vitesse compte. Quand quelque chose est suffisamment lent assez longtemps, mon esprit part ailleurs, et ça abîme fortement l’état de flow
      La vidéo compare côte à côte le temps nécessaire pour ouvrir une PR et aller vers un fichier spécifique. Pour moi, c’est une tâche quotidienne assez courante
      https://x.com/mitchellh/status/2057229385963618787

  • Cela ressemble beaucoup à pulldash (créé par coder.com) ou à difit (un CLI qui lance une page localhost)
    Je n’aime pas vraiment les deux. pulldash était un peu saccadé, et difit demandait un effort supplémentaire. Pour l’auto-review, j’utilise actuellement l’extension VSCode git tree compare
    C’est rapide, et j’aime aussi son design visuel global. Je l’ai testé avec l’une de mes PR et ça m’a semblé tout à fait correct, donc je pourrais même l’ajouter à mes favoris sur PC