DiffsHub

 (diffshub.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 대형 GitHub diff를 브라우저에서 빠르게 훑어봐야 할 때, DiffsHub는 공개 diff를 가상화 인터페이스로 보여주는 도구임
  • GitHub URL의 github.com을 diffshub.com으로 바꾸면 PR, 비교, 커밋, diff, patch 변경 내용을 바로 볼 수 있음
  • 별도 변환 절차 없이 기존 URL 구조를 유지해, github.com/org/repo/pull/number를 diffshub.com/org/repo/pull/number처럼 바꿔 접근함
  • Linux v6.0...v7.0 같은 수백만 줄 비교도 다룰 수 있지만, 모바일 브라우저에서는 가끔 크래시될 수 있음
  • GitHub는 100k 줄 초과 diff에서 첫 바이트 응답이 지연되고 안정적으로 제공되지 않을 수 있어, 큰 변경 검토 시 대안으로 볼 수 있음

GitHub URL 그대로 쓰는 diff 뷰어

  • DiffsHub는 공개 GitHub diff를 빠르고 보기 좋은 가상화 인터페이스로 확인하는 도구임
  • 지원 대상은 PR, 비교, 커밋, diff, patch임
  • 사용자는 GitHub URL에서 도메인만 바꿔 접근함
    • github.com/org/repo/pull/number
    • diffshub.com/org/repo/pull/number

수백만 줄 diff와 제약

  • DiffsHub는 수백만 줄 규모의 비교도 다룰 수 있음
  • 예시로 Linux v6.0...v7.0 비교를 볼 수 있음
  • 이런 대형 비교는 모바일 브라우저에서 가끔 크래시될 수 있음
  • GitHub는 100k 줄 초과 diff를 지연된 첫 바이트와 함께 불안정하게 제공할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • diff 보기와 vibecoding 태그가 무슨 관련인지 이해하려고 했음
    이후 맥락과 드라마를 따라잡고 왜 이렇게 됐는지 이해함. 소음 만들어서 @quad에게 미안하고, 이제 태그도 제거된 걸 봄

    • Lobsters가 좀 이상한 국면에 들어가서, 프로젝트가 “vibecoded처럼 보이는지”를 사람들이 마음대로 판단하고 있음
      예를 들면 낮은 코드 품질, 적은 커밋 수, 심지어 저장소에 CLAUDE.md가 있다는 이유만으로도 vibecoding 태그를 붙이는데, 별 의미가 없어 보임
    • 저장소에 CLAUDE.md가 있었음. 여기서는 잘못 제거됐고, 이 글에는 적절한 태그였다고 봄
    • 다행히 그 태그는 이제 사라진 것 같음

  • 추가 맥락으로는 이 글이 관련 있어 보임: On Rendering Diffs
    홈페이지에 링크된 Linux diff를 둘러볼 때도 꽤 부드러워서 인상적임. 스크롤바를 직접 드래그해 보면 알 수 있음. Github나 다른 브라우저 기반 diff 편집기, 직장에서 쓰는 Graphite도 이 정도로 부드러웠으면 좋겠음
    한편으로는 이런 데 감탄한다는 사실 자체가 이상함. 원래 이게 표준이어야 하는 거 아닌가 싶음

    • diff 렌더링 작업 대부분을 한 사람과 그 글의 저자를 알고 있음. 진행 중에 문자로 실시간 업데이트를 받았는데, 얼마나 많은 조사와 작업을 쏟아부었는지 정말 대단했음
      말 그대로 몇 달 동안의 풀타임 업무가 diff를 빠르게 렌더링하게 만드는 일이었음
      참고로 “vibecoding” 태그가 붙었지만, 여전히 이해가 안 가고, 이 작업은 전혀 그런 류가 아니었음. 대부분은 어려운 조사, 브라우저 구현 코드 읽기, 시행착오, 문제를 정석적으로 파고드는 일이었음
      아주 좁고 보상이 명확한 탐색 작업에는 에이전트 루프가 쓰였지만, 내가 알기로는 사람의 통찰과 검토 없이 들어간 건 없었음. 블로그 글에서도 이 부분을 다루는 것 같고, 전체 작업에서 정말 작은 비중이었음. 그 이유만으로 공학적 노력을 폄하하는 건 말이 안 됨
      블로그 글을 읽거나 코드를 보는 걸 강력히 추천함. 놀라운 작업이고 배울 게 많음
    • 정말로 이 정도가 표준이어야 함. Gitlab과 Forgejo도 이걸 받아들였으면 좋겠음
      직접 테스트해 보려고 북마클릿을 만들었음: 
      javascript:(function(){window.open(window.location.href.replace('github.com','diffshub.com'),'_blank');})();
      아쉽게도 많은 PR, 특히 큰 PR은 댓글 기능이 필요함. Pierre가 언제 이 영역까지 가져가서 예를 들면 https://www.reviewable.io/ 같은 걸 만들지 지켜봐야겠음

  • npmjs는 Apache 2라고 하는데 저장소에는 라이선스가 없고 package.json에는 "private":true까지 있어서 이유를 찾기 어려웠음
    답은 각 디렉터리가 개별적으로 라이선스되는 구조인 것 같음: https://github.com/pierrecomputer/pierre/…
    그리고 diffshub 자체는 오픈소스 부분에 포함되지 않는 듯함: https://github.com/pierrecomputer/pierre/…
    이런 수술식 라이선스 방식은 https://github.com/pierrecomputer/pierre/… 같은 디렉터리를 애매한 상태에 둠. 그 디렉터리에는 Apache 2 LICENCE.md가 없기 때문이고, package.json 필드가 권위 있다고 본다면 얘기가 달라질 수는 있음

  • UI는 대비만 빼면 Github보다 나아 보임. 접근성은 잘 모르겠음

  • 참고로 Github의 모든 pull request는 뒤에 .diff를 붙이면 diff를 받을 수 있음
    예: https://github.com/oven-sh/bun/pull/30412.diff
    .patch를 붙이면 git am에 넘길 수 있는 형태도 받을 수 있음: https://github.com/oven-sh/bun/pull/30412.patch

    • error: too big or took too long to generate
      이 이유 때문에 일부러 이 PR을 고른 건가? :D

  • 도구에 대한 기대치가 다른 사람들보다 낮은 건지도 모르겠지만, 이걸 Github 자체 기능과 비교했을 때 실용적인 차이를 잘 모르겠음
    모두 Github가 얼마나 나쁜지 한탄하는데, 나는 같은 경험을 해보지 못했음. 왜 Github 대신 이걸 써야 하는지 모르겠음

    • 왜 이게 내게 중요한지 보여주는 영상을 녹화했음. 영상이 X에 있어서 미안하지만 거기에 올려둠
      역사적으로 이게 내 일반적인 경험이었고, 왜 속도가 중요한지도 설명함. 어떤 작업이 충분히 오래 느리면 내 생각이 다른 데로 흘러가고, 그게 몰입 상태를 크게 망침
      영상은 PR을 열고 특정 파일로 이동하는 데 걸리는 시간을 나란히 비교함. 나에게는 꽤 흔한 일상 작업임
      https://x.com/mitchellh/status/2057229385963618787

  • pulldash(coder.com 제작)나 difit(로컬호스트 페이지를 띄우는 CLI)과 꽤 비슷해 보임
    둘 다 별로 좋아하진 않음. pulldash는 좀 버벅였고 difit은 추가 노력이 필요했음. 셀프 리뷰에는 지금 git tree compare VSCode 확장을 씀
    이건 빠르고 전체적인 시각 디자인도 마음에 듦. 내 PR 하나로 시험해 봤는데 충분히 괜찮아 보였고, PC에서 북마크해 둘 수도 있겠음

답변달기