▲
GN⁺ 4시간전 | parent | ★ favorite | on: 나만의 GitHub를 만든다면(matduggan.com)
Hacker News 의견들

  • PR 승인은 너무 이분법적이라는 비판은 모순처럼 보임. PR 승인은 권한 부여라서 결국 불리언일 수밖에 없고, 코드를 병합할 수 있거나 없거나 둘 중 하나임
    여기서 말하는 건 싫어하는 코드를 승인하면서 “나중에 다시 봐야 함...” 같은 말로 마음을 조금 편하게 만드는 장치에 가까움. 그냥 새 티켓을 열면 됨

    • Gerrit에는 -2부터 +2까지 있음
      -2: 나쁜 아이디어니 하지 말 것
      -1: 좋은 아이디어지만 개선 필요
      +1: 좋아 보이나 승인할 지식이나 권한이 부족함
      +2: 승인
    • “이 3개 커밋은 지금 승인하고 병합, 이 2개는 재작업 필요”라고 말하는 버튼이 있었으면 함
    • 코드가 승인됐지만 병합되지는 않는 경우도 있음. 이때 관리자가 변경을 더해 수동으로 적용하고, 그 변경 커밋의 공동 저자로 PR 작성자를 올릴 수도 있음
    • 더 큰 문제는 GitHub가 이슈 추적 시스템과 너무 분리돼 있다는 점으로 보임. 계속 수동으로 동기화해야 하는 부담이 크고, Linear가 어느 정도 해주긴 하지만 이상적이진 않음
    • “코드를 병합할 수 있거나 없거나 둘 중 하나”라니, 직관주의자는 아닌 듯함

  • “Y도 그중 일부를 한다”는 말은 맞지만, tangled.org는 실제로 그 대부분을 함

    1. 버전 관리 시스템으로 JJ 사용: tangled는 jj change-id로 누적 PR을 지원함. https://blog.tangled.org/stacking tangled 자체도 이 방식으로 많이 만듦: https://tangled.org/tangled.org/core/pulls
    2. Raspberry Pi에서 오래 돌릴 수 있는 forge: 이것도 가능함. git 서버 shim은 매우 가볍고, git 저장소 위의 XRPC 계층과 sqlite3 데이터베이스일 뿐임. RAM 512MB짜리 RISC-V 보드에서 돌리는 사람도 있음
    3. Actions는 중요하고 로컬 머신에서 실행 가능해야 함: 이 요구는 약간 빗나갔다고 봄. 밀폐적이고 어디서나 실행되며 교차 빌드를 처리하는 건 대체로 빌드 시스템의 일임. 그런 빌드 결과를 forge 자체로 “승격”할 수 있으면 정말 좋을 것 같음
    • 워크플로에 핵심인 데이터를 호스팅하는 데 Raspberry Pi가 나온 게 의외임. 예전에 SD 카드 손상으로 너무 많이 당했는데, 요즘은 NVME 드라이브를 쓰는지 궁금함
    • 맞음, 그건 빌드 시스템의 일임. 다만 사람들이 로컬 실행 가능한 Actions로 풀고 싶어 하는 문제는 대부분 빌드 실패 자체가 아니라 전체 통합임
      YAML 정의, 비밀값, 정확히 어떤 명령을 실행하는지, 도구와 캐시를 어떻게 복원하는지 같은 부분임. 빌드 시스템이 일부 처리할 수도 있지만, GHA에서 제공하는 원시 기능은 매우 빈약함. 결국 전체 시스템을 다른 곳에서 돌려야 하는 문제로 귀결되기 때문에, 이런 시스템들은 대개 시행착오 방식이 되는 듯함
    • 맞고, 더 나아가 밀폐 빌드 개념을 확장해서 로컬이나 계산 자원이 있는 어디서든 쉽게 돌릴 수 있으면 좋겠다는 뜻임
      여기서 부르는 근본 문제는 변경, 커밋, 네트워크 호출이 끼어 있는 순환 속에서 CI가 초록불이 될 때까지 돌리는 일이 매우 고통스럽다는 점임. 이 반복을 피하는 최고의 방법은 버그를 절대 쓰지 않는 것뿐임! 농담임
    • Radicle과 Tangled는 둘 다 핵심을 놓침. 이들은 공개 협업 작업용인데, 비공개 저장소는 어떻게 할 건가? 많은 사용자가 사이드 프로젝트를 하고, 이를 위해 GitHub private을 씀
      GitHub를 배우면 공개 프로젝트도 GitHub에서 시작하게 됨. 사이드 프로젝트용 비공개 저장소를 만들 수 있게 해주기 전에는 널리 쓰이기 어려움. 사람들이 원하는 건 비공개 저장소를 만들고 몇 달 떠났다가 돌아와도 그대로 기다리고 있는 것임
    • 와, Tangled의 jujutsu 지원이 정확히 찾던 것임. 이번 주말은 셀프 호스팅 세팅으로 사라지겠음

  • 제한된 이력만 클론하고 필요할 때 과거 데이터를 가져오고 싶다면 blobless clone을 쓰면 됨
    git clone --filter=blob:none
    이력은 가져오고 blob은 필요할 때만 가져옴. GitHub에 좋은 글이 있음: https://github.blog/open-source/git/get-up-to-speed-with-par...

  • 해법이 문제가 되면 파괴적 혁신의 기회가 열림. 요즘 이 이야기가 꽤 많고, GitHub가 방향을 고치기 전에 새로 뜨는 많은 대안 중 하나라도 탄력을 받을지 궁금함

    • 문제는 Microsoft가 AI에 완전히 올인했다는 점이라고 봄. 되돌아갈 길이 없고, GitHub도 그 영향을 받을 수밖에 없음
      Microsoft 홍보는 AI가 모든 것의 해법이라고 말하겠지만, 현실에서는 같은 문제가 계속 반복될 것임. GitHub 서비스 장애가 AI와 직접 관련 없을 수는 있어도, Microsoft의 전략이 이미 바뀌었기 때문에 대부분의 판단은 AI 중심의 하향식 통제에 맞춰질 것임. GitHub를 쓰는 사람들의 워크플로가 깨지는지는 Microsoft에겐 기껏해야 부차적인 관심사이고, 그 문제는 계속 다시 나타날 것임. 3개월쯤 조용할 수는 있어도 머지않아 GitHub가 쇠퇴한다는 새 드라마가 100% 또 나올 거라고 봄. Ghostty가 마지막은 아닐 것임. 대안이 나올지는 흥미롭지만, 그 대안들이 구리면 안 되는데 많은 웹사이트들이 꽤 별로임
    • 내 도구는 직접 만들고 있음. 사람들도 자기 도구를 직접 만들어야 한다고 생각함
      미래에는 유료 소프트웨어나 오픈소스 소프트웨어 대신 코드 forge를 위한 요구사항 문서 묶음, 일종의 레시피를 받게 될지도 모름. 각자 직접 굽고, 자기 용도와 취향에 맞게 바꾸는 방식임

  • 훨씬 단순한 git 서비스에 시장의 빈틈이 있다고 봄. 필요한 건 다른 사람들이 볼 수 있도록 프로젝트를 push할 원격 호스트뿐이고, PR이나 Actions 같은 건 딱히 원하지 않음
    로컬에서 빌드한 바이너리 자산을 올리는 “릴리스” 기능 정도는 있으면 좋겠음. 포크는 사람들이 저장소를 클론해서 새 프로젝트로 올리면 처리 가능함

    • 필요 없는 기능을 끄면 이 중 많은 걸 해결할 수 있지 않나? 방금 내 Forgejo 인스턴스를 보니 저장소별로 Code, Projects, Releases, Packages, Actions, Issues, PRs, Wikis를 끄는 옵션이 있음
    • https://sr.ht/
    • 그럼 다시 cgit으로 돌아가는 건가?

  • 리뷰 데이터도 소스처럼 git 저장소에 넣을 수 있다는 주장은 꽤 설득력 있음
    알려진 접두사를 붙여 리뷰마다 브랜치를 두면 아주 쉽게 구현할 수 있지만 기본 브랜치 이름공간이 금방 지저분해질 것임. git namespaces로 메인 이름공간과 분리하거나, 각 리뷰 브랜치의 끝 커밋 ID만 담는 .reviews 같은 특별 브랜치를 둘 수도 있음. 누군가 충분히 관심을 갖고 명세와 실사용 가능한 구현을 만들면 사람들이 채택하기 시작할지도 모름. GitHub와 여러 forge가 이 방식을 택하지 않은 이유는 리뷰 메타데이터를 자기 생태계 안에 묶어두는 것이 플랫폼 가치이기 때문일 것 같음. 누구나 원하는 로컬 도구로 남의 코드를 리뷰할 수 있다면 공급자 고착이 줄어듦. 다만 접근 제어나 저장소 간 리뷰처럼 리뷰 메타데이터를 다른 저장소에 두고 싶은 다른 이유도 있겠음

  • PR이 아니라 차이를 리뷰하는 Gerrit 워크플로를 정말 좋아함. 하지만 gitea 같은 것과 비교하면 이슈, 프로젝트 계획 등 git 호스팅에서 기대하게 된 나머지 기능이 부족해서 많은 사람에게 설득하기 어려워 보임
    Phabricator 같은 괜찮은 차이 리뷰 플랫폼이 있으면 좋겠지만 아쉬움

    • 그런데 왜 Gitea는 그걸 추가하지 않을까? 이미 나머지는 다 있는데, 왜 이런 forge들은 항상 GitHub 복제판에 머물고 더 나아가지 않는지 모르겠음

  • PR, 리뷰 댓글, 이슈 같은 모든 메시지 저장의 기본 형식으로 RFC2822를 쓰고, 메시지를 표시할 때는 CommonMark로 꾸미면 된다고 봄
    모든 메타데이터는 헤더에 넣고, Message-ID/In-Reply-To/References 헤더로 서로 연결할 수 있음. 이렇게 잘 정의된 형식을 쓰면 모든 메시지를 어떻게 저장하고 전송할지 선택할 수 있음. git 저장소에 넣거나, 이메일을 쓰거나, 다른 맞는 방식을 쓰면 됨. 코드 리뷰는 개인적으로 Gerrit이 GitHub 등보다 훨씬 낫다고 생각함. CI는 가능한 한 밖에 두고, 파이프라인을 시작하고 결과를 표시하며 병합 허용 여부를 결정하는 훅 정도만 두고 싶음

    • GitHub의 매력 중 하나는 코드 리뷰, 소스 탐색, 티켓 추적, CI 네 가지를 통합한다는 점이라고 봄
      네 가지 모두에서 대단히 잘하지는 못하지만, 한데 묶는 일은 잘함. Gerrit이 더 나은 코드 리뷰 모델이라는 데는 동의하지만, 나머지 세 조각이 없으면 제품이 되지 않음. Google에서 Gerrit을 매일 쓰던 때에도 코드 검색과 코드 리뷰, CI 사이의 빈약한 통합이 불만이었음. Google3/Critique/Forge 같은 Google 내부 도구는 이 모든 걸 훨씬 잘 엮어줬음

  • 이메일 기반 워크플로의 장점 하나가 떠오름. 이메일을 보기 시작했다면 보통 그럴 마음 상태일 때이고, 그 상태에서는 다른 방해가 없을 거라고 예상하므로 더 집중하게 됨
    알림의 문제는 뜨는 대로 치우고 싶어지는 힘이 있다는 것임. 하지만 그 순간에 그걸 처리할 에너지가 있다는 보장은 없음. 웹의 알림 시스템 대부분은 이메일 클라이언트가 수십 년 전에 이미 달성한 것을 서투르게 흉내 낸 것처럼 보임. 어쩌면 옛사람들이 이메일을 쓴 게 정말 맞았던 것 같음

    • 이메일도 알림인데, 도착하는 순간 어떻게 그걸 받을 기분이 된다는 건지 더 명확히 설명해줄 수 있나

  • Microsoft가 GitHub를 흡수했을 때 이미 많은 사람이 짜증났음. 다만 현실적으로 대안들이 자주 별로였음. Sourceforge는 이슈 만들기가 끝없이 짜증나고, GitLab은 Sourceforge보다는 낫지만 거기서도 이슈 만들기가 싫음. Codeberg는 최근 UI가 바뀐 것 같지만 여전히 꽤 불편함
    GitHub가 처음에 잘한 건 UI와 GitHub를 쓰는 사람들에게 초점을 맞춰 일을 쉽거나 더 쉽게 만든 점임. 다만 전부 잘한 건 아니고, 위키 지원은 끔찍하다고 봄. 너무 별로라 위키는 거의 쓰지 않음. 정말 큰 문제는 상업적 이해관계, 즉 사적 이해관계라고 생각함. Microsoft는 한 예일 뿐이고, 비슷한 사이트들 거의 어디에나 있는 문제임. 예전에 xz 백도어 유틸 관련 이슈 토론을 예로 들었고 나도 토론에 참여했는데, 다음 날 Microsoft가 전부 내렸음. Microsoft였는지 저장소 소유자였는지는 중요하지 않음. 문제는 개인이 잠재적으로 유용한 정보를 너무 쉽게 검열할 수 있다는 점임. 그 이슈 토론은 유용했고 검열됐음. 당시 정보가 전부 복원되지는 않았던 것으로 기억함. 누군가 미러했을 수도 있지만 링크는 못 봤음. 이는 하향식 통제가 정말 해로울 수 있음을 보여줌. 솔직히 Microsoft를 얼마나 신뢰할 수 있나? 탈중앙적이고, 안정적으로 잘 동작하며, 기본 UI가 좋고, 단순하거나 최소한 좋은 워크플로가 필요함. 사적 행위자가 모두를 인질로 잡는 상황도 피해야 함. 어떻게 풀지는 전혀 모르겠고, 여러 접근이 동시에 필요할지도 모름. 웹은 변했고, 특히 거대 초대형 기업의 사적 이해관계가 지난 10~15년 동안 상황을 훨씬 나쁘게 만들었다고 느낌. 바뀌어야 함

    • 문제는 SaaS 제품 운영에 돈이 많이 든다는 점임
      거대 기업은 그 비용을 댈 수 있지만, 예산이 작은 개발자가 많이 모여도 같은 일을 할 돈은 없음. 그래서 어떤 상업 프로젝트든 결국 평균적인 사람보다 거대 기업의 이해를 더 지원하는 방향으로 갈 수밖에 없음