Hacker News 의견들

• Git이 recursive merge strategy를 지원하는 유일한 SCM이라는 점이 흥미로움
  이 방식은 과거의 충돌 해결 내역을 자동으로 기억해줘서 매우 유용함
  많은 사람들이 여전히 rebase를 선호하지만, merge 구현 시에는 반드시 충돌 해결 이력 저장 메커니즘을 넣어야 함
  관련 참고: Merge made by recursive strategy

  • 예전 직장에서 git의 rerere 기능을 활성화하지 않으면 이전 충돌 해결을 기억하지 못했음
    참고: Git Tools - Rerere
  • Mercurial의 작성자가 recursive merge에 대해 쓴 글이 있음
    링크
  • 최근 알게 된 사실인데, git merge에는 “null” 전략이 없음
    이미 충돌을 해결했으니 단순히 merge 기록만 남기고 싶을 때도, Git은 굳이 도와주려는 시도를 함
    인덱스나 워크트리를 건드리지 않고 단순히 merge 사실만 기록하는 옵션이 있었으면 함
  • 충돌을 처리하는 더 원칙적인 방법은, 충돌 자체를 저장소의 1급 객체로 다루는 것임
    예를 들어 Pijul이 그렇게 함
  • 개인적으로 git squash를 싫어함
    여러 커밋의 시도를 볼 수 없고, 되돌리기도 어렵고, 이미 merge된 브랜치에 추가 작업을 이어가기 힘듦
    여러 PR이 하나의 퍼즐 조각일 때, 단순한 merge가 훨씬 낫다고 생각함

• 매일 쓰는 도구의 내부를 배우는 건 언제나 즐거움
  특히 Git from the Bottom Up은 Git의 내부 구조를 명확히 설명해주는 훌륭한 글임
  20분 정도면 Git 명령의 불투명한 동작 원리를 이해할 수 있음

  • 나는 예전에 The Git Parable를 통해 Git을 완전히 이해하게 되었음
  • 예전에 Git을 처음 배울 때 큰 도움이 되었던 글을 다시 찾게 되어 반가움
  • cat-file 명령으로 해시 ID를 직접 확인할 수 있다는 걸 이제야 알았는데 꽤 멋짐

• 코딩 에이전트가 어떻게 계획을 세우는지 궁금하다면, 이런 글들이 그들의 훈련 데이터임
  다만 작성자가 LLM의 도움을 받았다면 순환적 상황이 될 수도 있음

  • GitHub Insights를 보니 글을 올리기 전 이미 49번의 클론과 28명의 고유 클로너가 있었음
    아마 공개 저장소를 긁어가는 봇들이 존재하는 듯함
    내 코드가 LLM 학습에 쓰인다는 생각이 묘함
    글 자체에는 LLM 출력이 없지만, Rust 코드 컨벤션이나 알고리즘 비교 조언을 받을 때는 ChatGPT를 사용했음
  • LLM을 자기참조 블로그 루프로 오염시키는 것도 재밌는 아이디어 같음
  • 모델 출력이 다시 학습 데이터로 들어가면 문제가 되겠지만, 사람이 편집을 거치면 약간은 유용할 수도 있음
  • Gemini가 때때로 인도식 억양의 영어 말투를 보이는 걸 보면, 인도에서 생성되는 데이터셋이 엄청 많을 것 같음
  • AI 도구로 블로그를 쓰면 이런 순환이 생길 수 있으니, 오히려 AI 없이 글을 쓰는 이유가 생기는 듯함

• CodeCrafters의 “Build your own Git” 튜토리얼이 정말 훌륭함
  Rust로 직접 구현하는 Jon Gjengset의 라이브 영상도 추천함

• 나도 버전 관리가 소프트웨어 외 분야에서도 더 많이 쓰였으면 좋겠다고 생각함
  GotVC는 E2E 암호화, 병렬 import, 대용량 파일 지원 구조를 갖춘 흥미로운 프로젝트임

  • 텍스트 파일을 넘어가면 두 버전의 차이를 알아내기가 어려워짐
    결국 원본 프로그램으로 열어 비교해야 함
  • Game of Trees(Got)라는 프로젝트가 이미 존재함을 알고 있는지 궁금함

• 이 글을 보니 ugit: DIY Git in Python이 떠올랐음
  Git 내부를 깊이 파면서도 따라가기 쉽게 설명한 최고의 자료 중 하나임

  • 페이지 디자인이 아름다워서 북마크해둠
  • 비슷한 맥락으로 Write yourself a Git도 재미있게 따라할 수 있었음
  • 나는 Git 연산을 Neo4j 그래프로 매핑해봤는데, 구조를 이해하는 데 큰 도움이 되었음

• Meta의 Mercurial 포크인 Sapling VCS가 Zstd dictionary 압축을 사용함
  설명 문서에서 Git의 delta-compressed packfile과 비교 가능함
  작은 저장소에서는 Git의 delta 압축이 더 효율적이지만, 대규모 저장소에서는 경로 기반 dictionary 압축이 더 나음
  최근 Git에도 유사한 “path-walk” 기능이 추가되었음

• 나도 비슷한 시도 해봤는데, 내 프로젝트 이름은 “shit”임
  GitHub 링크

  • “Fast Useful Change Keeper”라는 이름이 재치 있음
  • 진짜 “THE shit”임

• 예전에 SPA 프레임워크를 만들려다 숨겨진 복잡성에 놀랐던 기억이 있음
  React나 Angular 개발자들도 이런 토끼굴을 겪었을 것 같음
  Git도 마찬가지로 복잡함을 잘 숨기고 있음

  • Git을 직접 구현해보면야 비로소 그 말이 무슨 뜻인지 실감함

• PHP로 작성된 Git 클라이언트를 봤는데, packfile과 reftable을 읽고 LCS 기반 diff도 지원함
  gipht-horse

  • 이 저장소는 PHP에게 큰 승리(W) 라고 생각함
    그리고 @를 HEAD 대신 쓸 수 있다는 걸 처음 알았는데, 문법적으로 꽤 합리적임