Hacker News 의견

• jj를 두 번 정도 진지하게 써봤음. first-class conflict 개념은 멋지지만 실제로는 충돌 해결보다 staging/commit을 훨씬 자주 하게 됨. magit에서 오다 보니 jj의 hunk 분할과 선택 기능은 너무 불편하게 느껴졌음. 나는 rebase를 자주 하는 편이라 magit의 rebase 단축 기능으로 이미 jj의 장점을 대부분 누리고 있었음. 나 같은 사람에게는 jj가 magit을 이기려면 hunk 선택 UX가 훨씬 개선되어야 함

  • jj에서는 staging이나 commit을 생각하지 않는 게 핵심임. 모든 것이 변경(change) 이고, 부모나 더 먼 조상을 북마크로 지정해 그 안에 squash하거나 다음 변경으로 북마크를 옮기는 식으로 사고해야 함
  • 나도 rebase를 자주 하는데, jj의 너무 의견이 강한 버전 관리 철학은 별로임. 특히 초보자에게 내부 설계를 너무 숨기는 건 학습에 도움이 안 된다고 생각함
  • magit의 hunk 선택 UX가 구체적으로 어떤지 궁금함. jj의 것과 크게 다르지 않아 보였음. 나는 GitUp(gitup.co)을 오래 썼는데, jj의 UX가 완전히 자연스럽진 않지만 단축키 커스터마이즈로 해결될 문제 같음
  • Git 위에 좋은 UX를 얹는 게 왜 중요한지 이해한다면 jj의 철학 95%는 이미 이해한 것임
  • jj에서도 git index를 쓸 수 있음. 단, git_head를 바꾸는 jj 명령만 안 쓰면 됨. 나는 staged 변경으로 커밋하는 alias를 만들어서 쓰고 있음 (config.toml 예시)

• Git의 대안을 볼 때마다 약간 루다이트 감정이 듦. 이미 언어, 프레임워크, 도구가 너무 많음. 최소한 VCS만큼은 Git이라는 거의 보편적인 해법이 있어서 다행이라 생각함. jj가 문제를 해결할 수도 있겠지만, 업계가 두 시스템을 모두 지원해야 하는 부담을 생각하면 순이익이 아닐 것 같음

  • Git의 UI 부실함이 너무 짜증나서 대체되길 바람. Git의 개념을 더 잘 설명해주는 새로운 도구가 나왔으면 함
  • jj는 개발자 개인이 선택할 수 있는 옵션임. jj repo는 git repo의 상위집합이라 기존 도구들이 깨지지 않음
  • 예전에 svn을 쓰던 회사에서 git-svn으로 Git을 먼저 썼던 경험이 있음. jj도 비슷한 접근을 하는 듯함. jj를 몰라도 기존 CI나 툴이 그대로 작동함
  • Git은 생산성 저하 요인이고, 특히 에이전트 기반 코딩 시대에는 더 큰 문제임. jj는 충분히 혁신적이지 않다고 봄. 차라리 원자 단위(atomic) 로 변경을 추적하는 새로운 VCS가 필요함. 이런 구조라면 브랜치 개념이 사라지고, 계획(plan)과 원자(atom)로 리포 상태를 구성할 수 있음. 다만 이런 시스템으로 전환하는 건 엄청난 도전이 될 것임
  • rcs, cvs, svn을 거쳐 git이 나왔듯, git도 언젠가 더 나은 것으로 대체될 것임

• jj를 써봤지만 나는 Sublime Merge에 익숙함. CLI로 버전 관리를 하면 반복 입력이 많고 상태를 잃기 쉬움. GUI에서는 상태가 항상 보이고 클릭 한 번으로 diff나 커밋 메시지 입력이 가능함. 키보드로 hunk를 선택하는 건 다시는 하고 싶지 않음. SM은 정말 쾌적함. jj GUI가 발전하거나 SM에 jj가 통합되면 좋겠음

• 진짜 뉴스는 사람들이 “jjhub” 같은 걸 만들기 시작했다는 점임 (ersc.io)

  • ‘jjhub’은 괜찮은 첫 단계라 생각함. 이미 jj를 github과 함께 쓸 수 있지만, 그 이상으로 가치 있는 무언가를 제공해야 함
  • 참고로 이런 것도 있음: Stacking 블로그 글
  • Gerrit도 jj 개념과 잘 맞고, Jujutsu change ID 지원을 추가하는 RFC가 승인됨
  • jjhub라는 이름, 꽤 멋짐
  • 진심으로 성공하길 바람. Github의 진짜 대안이 나올 때가 됐음

• Google 내부에서 jj가 확산 중이라는데, Google은 주기적으로 내부 VCS를 바꾸는 경향이 있음. git wrapper, mercurial 확장판, 이제는 jj까지 7년 사이에 다 바뀜

  • 사실 Google 내부 도구 대부분이 수명이 짧음. 그래도 jj는 변경의 정체성(identity) 을 유지한다는 점에서 혁신적임. git에서는 rebase나 amend 후 완전히 다른 커밋이 되지만 jj는 동일한 변경으로 추적됨. 다만 jj도 결국 git을 저장 백엔드로 계속 쓸 가능성이 높음
  • jj가 계속 유지되길 바람. 회사와 집에서 같은 워크플로를 쓰고 싶음. mercurial보다 훨씬 빠름
  • 이번에는 Perforce fork도 같이 폐기하려는 의도 같음. 외부에서 보기엔 변화가 너무 많음
  • git wrapper는 원래 실험적이었고, mercurial 기반 시스템은 거의 10년 가까이 유지됨

• jj가 대용량 바이너리 파일을 git보다 잘 다루는지 궁금함. 게임 개발 쪽에서는 여전히 Perforce가 왕임. git은 LFS가 있어도 충분하지 않음

  • Perforce의 바이너리 지원은 사실상 Git LFS와 동일함. 차이는 기업용 지원 여부 정도임
  • jj는 git을 저장소로 쓰고 LFS를 지원하지 않아서, 이 부분은 git과 동일한 한계를 가짐
  • 현재로선 특별한 개선은 없지만, 이 영역은 인지하고 있고 앞으로 변화가 있을 수도 있음

• 하루 정도 Jujutsu 튜토리얼을 따라 해봤는데 꽤 괜찮았음. 다만 뭔가 빠진 퍼즐 조각이 있는 느낌이었음. 예를 들어 GitHub에 PR을 올릴 때 change id가 실제로 도움이 되는지 궁금했음. 아마 Google 내부 Piper 백엔드에서만 진가를 발휘하는 듯함. ERSC의 계획이 궁금함. 개인적으로는 오프라인 코드 리뷰가 내장된 분산형 워크플로우를 원함

  • 즐겁게 써봤다니 기쁨 :) 현재 GitHub에서는 change id의 이점이 거의 없음. 하지만 jj-spr 같은 도구로 일부 경험을 얻을 수 있음. GitHub SVP가 jj에 관심을 보였다는 트윗도 있었음. 또, 이슈를 리포 안에 넣는 시스템으로 beads를 써봤는데 꽤 마음에 듦
  • jj로 만든 커밋에는 change-id 헤더가 포함되어 있어서, GitHub이 jj를 몰라도 jj 사용자끼리는 rebase 추적이 가능함. git cat-file -p HEAD로 확인 가능함

• 개인 프로젝트에 jj를 1~2개월 써봤는데 꽤 만족스러움. 다만 예전 리비전을 수정할 때 .gitignore에 새로 추가된 파일이 실수로 포함될 수 있음. 그 외에는 좋음. 그래도 아직은 Git 지식이 훨씬 많음, 천천히 회사에도 도입할 예정임

• 올해 Sapling/Subversion 회사에 합류했는데 jj는 아직 못 써봄. 그래도 Sapling은 훨씬 직관적이고, 커밋 스택이 브랜치보다 이해하기 쉬움. 다만 Meta의 리뷰 UI 같은 지원이 없으면 어떻게 될지 궁금함. 이런 프로젝트가 꼭 필요함

  • 맞음, Sapling과 jj는 같은 방향의 동료 프로젝트임

• 이름이 뭐라 해도 East River Source Control은 정말 멋진 이름임