Hacker News 의견

• jj를 배울 가치가 있는지 고민하는 분들께 강조하고 싶은 점이 있음
  Hacker News에서 jj에 대해 얘기하면, 두 부류로 나뉨: 아직 시도해보지 않은 사람들과 강력 추천하는 사람들임
  일주일간 jj를 써본 뒤 다시 git으로 돌아가는 경우는 거의 본 적이 없음
  정말 진지하게 써본 사람들은 거의 다 jj에 정착했음
  오늘이 바로 jj를 써보는 계기가 되길 바람
  생각보다 전환이 훨씬 간단하고, 나는 당일에도 바로 생산성을 유지했고, 일주일 안에 git 커맨드로 돌아갈 일이 전혀 없었음
  짧은 시간 안에 더 생산적으로 변했고, 이전에 어떻게 git을 썼는지 신기할 따름임

  • 나는 git이 생산성 측면에서 전혀 불편하지 않음
    git 커맨드를 매일 오래 쓰는 것도 아니고, 대부분의 경우 작업에 무리가 없음
    레포를 git으로 많이 조작해야 한다면 jj가 더 나을 수 있지만, 내 상황엔 해당되지 않음
    예를 들어, vim과 매우 비슷하면서 다른 기능이 추가된 bim을 무조건 써보라는 제안과도 유사함
    하지만 "i"를 몇 번 더 치는 게 궁금하지 않고, julia 자동완성도 필요하지 않음
    jj가 더 좋은 분들은 즐기시길 바람

  • jj는 VCS UI에서 확실히 발전이긴 하지만, git 고급 사용자라면 몇 가지 한계점이 있음
    gitattributes 미지원으로 git-crypt, git-lfs 등 필터가 필요하면 불편함
    줄 끝 처리 등 Windows에서의 호환성도 떨어질 수 있음
    또, git-annex, git-bug 같은 외부 툴은 oplog 통합 안 되고 히스토리 어지럽힐 수도 있음

  • 나는 실제로 일주일 넘게 써보고 다시 git으로 돌아간 경험이 있음
    개인적으로 staging area의 워크플로우가 더 좋아서, 대부분은 git staging을 싫어하지만 나는 오히려 그게 jj에서 버릴 만큼 이득이 크지 않았음
    습관은 바꿀 수 있겠지만, 아직 jj에 굳이 안 얽매임
    언젠가 다시 시도할 마음은 열려있음

  • 몇 달간 jj를 썼다가 다시 git으로 돌아갔던 이유는 성능 문제였음
    jj 조작은 수 초가 걸렸고, git은 프로젝트 크기와 관계없이 즉각적이었음
    또 jj를 쓰면 약간 더 정신적으로 복잡해지는 느낌을 받았고, 다시 git으로 오니 한결 가벼워짐
    이건 나만의 장기간 git 사용 경험 때문일 수도 있음

  • “어차피 두 부류뿐”이라 말하는 자체가 jj 전도사들의 전형적 멘트 같음

• jj에서 미치는 점은 변경사항이 무조건 자동 staging되었다는 점임
  SVN 체계가 예전에 그랬고, git은 명시적으로 staging해서 훨씬 개선되었다고 느낌
  레포에는 늘 더 많은 변경이 남아 있고, 다음 커밋에 넣고 싶은 것만 선택하는 게 git에선 당연한데
  jj(SVN 포함)는 커밋 전 변경을 임시로 밖으로 옮기는 등 번거로운 수작업이 필요함

  • 이 이슈는 나도 딜레마임
    staging이 항상 귀찮아서 Mercurial 쓸 때도 힘들었음
    자동 추가가 90% 이상 필요한 경우엔 오히려 편한데, .gitignore에 못 넣는 파일들이 문제임
    auto add를 꺼도 불편해지고, 켜도 애매함
    어느 쪽도 완전히 깔끔하지 않음

  • JJ의 워크플로우는 약간 다르니, 예를 들어 베이스 커밋을 먼저 만들고, 그 위에 익명 커밋을 쌓아서 작업
    준비가 되면 jj squash나 jj split으로 정리하게 됨

  • 나는 jj commit -i나 여러 명령의 -i 옵션, 그리고 config의 snapshot.auto-track="none()"을 씀
    Mercurial 쓸 때도 비슷했음
    실제론 absorb 기능을 많이 쓰면 불필요한 파일이나 청크는 자동으로 무시됨

  • “jj new” 명령어가 원하는 워크플로우에 적합한 것 아님?

  • jj는 트리 상에서 head가 아닌 브랜치도 제대로 추적하기 때문에, 리베이스와 머지가 stash 필요 없이 매끄럽게 작동함

• 자동 변경 추가에 적응하기가 쉽지 않음
  로컬에서 특정 파일은 커밋할 생각 없이 개발 과정에서 잠깐 변경할 때가 있는데
  git에선 staging하지 않으면 절대 커밋/푸시 안 되니 안심되지만
  jj에선 뭔가 unstage하거나 조심해야 할 것 같음
  습관 문제일 수 있겠으나, 나는 내가 커밋할 것만 명확히 지정하는 게 더 편함
  혹시 내가 jj를 잘못 이해한 것인지 궁금함

  • jj에선 jj split으로 변경점을 나눌 수 있음
    선택하면 첫 번째 리비전, 나머지는 두 번째 리비전으로 정리됨
    여러 작업을 한 번에 하고 bite-sized 리비전으로 나눴을 때 git보다 훨씬 수월함
    git처럼 새 리비전(jj new) 만들고 바꾼 후, jj squash -i로 딱 원하는 부분만 옮길 수 있음
    개념적으로 “@”가 현재 리비전, “@-”가 한 단계 전이니 git의 워킹 카피/스테이지처럼 생각하면 됨

  • jj의 자동 스테이징이 항상 좋은 게 아님
    jj 공식문서와 입문자들이 기본값을 쉽게 끌 수 있다는 점을 더 명확히 알렸으면 함
    ~/.jjconfig에
    [snapshot]
    auto-track = "none()"
    이렇게 적으면 됨

  • 나는 주로 작업 후 jj split으로 커밋할 부분을 리뷰해서 정리함
    이 워크플로우는 git의 add -p랑 비슷하게 움직임
    맨 위 커밋은 보통 push하지 않는 워킹 카피처럼 쓸 수 있음
    스태시 없이 브랜치 전환해도 진행중인 내용은 잘 보존됨

  • 네, 그 습관이 나도 쉽지 않게 바뀜
    바꿔야 한다는 주장의 합리적 근거는, untracked 상태로 코드를 돌리면 안 된다는 것임
    의미 있는 변경은 커밋에 남기고, 나머지는 기록하지 않는 게 더 안전함
    문제는 레포 전체의 설정과 로컬 설정이 분리되지 않을 때인데, VSCode가 대표적임
    이럴 땐 환경별로 커밋해선 안 되는 변경이 필요해져서 더 복잡해짐

  • 이런 워크플로우를 원하면, jj의 “@”를 git index처럼, 커밋 타임에 “@-”로 squash 하면 git add --patch와 비슷한 효과를 얻을 수 있음

• 팀을 jj로 바꾸려다 실패 중임
  git에서 복잡한 작업을 jj로 얼마나 쉽게 할 수 있는지 한눈에 보여주는 페이지가 있으면 좋겠음
  엘리베이터 피치 마냥 간단히
  내가 직접 데모해서 보여주는 것도 필요하겠다는 생각임

  • 많은 사람들이 흔히 쓰는 git 작업이 jujutsu에서 더 쉬운 건 아닌 듯함
    오히려 git에선 불가능하거나 번거로운 새로운 워크플로우가 jujutsu에 있음
    이건 기존 git에 익숙한 개발자들에겐 잘 와닿지 않을 수 있음

  • 나 역시 git을 특별히 좋아하는 건 아님
    과거엔 mercurial만 썼었는데, 지금은 git이 이미 머릿속에 박혀있음
    Jujutsu가 뭔가 확실한 장점이 있어도, 초기 셋업(복잡한 컬러 세팅, 익숙한 스크립트 세팅 등)까지 신경 쓸만큼의 매력은 아직 못 느낌

  • 나는 jj와 git의 한 가지 대표 작업 비교가 큰 이해를 도왔음
    https://lottia.net/notes/0013-git-jujutsu-miniature.html

  • 도움이 될만한 좋은 링크들도 추천함
    https://v5.chriskrycho.com/essays/jj-init/
    https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/
    https://ofcr.se/jujutsu-merge-workflow

  • 내가 이 포스트에 곧 추가할 다음 내용이 아마 마음에 들 것임
    조만간 페이지 하단과 별도 포스트로 올릴 예정임

• 몇 주 jj를 쓰다가 자동 커밋 메시지 스크립트도 제작함
  오늘 오랜 git 레포에서 같은 스크립트를 포팅하려고 했는데, git에선 커밋/어멘드 시점을 자동 판별할 코드가 필요하다는 걸 깨달았음
  jj는 immutable 커밋 구조 덕분에 스크립트가 매우 간단했음
  그냥 jj로 레포를 새로 클론함
  커밋과 어멘드 헷갈림에서 순식간에 해방되었음
  https://codeberg.org/jcdickinson/nix/src/branch/main/home/common/scripts/jj-auto.fish

  • 꼭 re-clone 할 필요 없이, 기존 git 레포에 jj를 추가로 쓰면 됨

• git이 충분히 잘 작동함
  학습 곡선이 조금 있을 뿐, 일단 익히면 모든게 이해됨
  솔직히 95%의 상황에서 pull, add, reset, branch, commit 정도만 알면 충분함

  • 내 워크플로우에선 stacked diff가 필수임
    리뷰 기다리느라 막히지 않고 미래 작업까지 쌓아두기 좋음
    git에서 세팅은 안 어렵지만, 스택 아래쪽에 변경 추가하고 전체 restack 하는 건 정말 헬임

  • 협업하는 경우엔 rebase/squash 숙지가 필수임
    팀 전체가 안 쓰도록 설득하기 전엔 피할 수 없음
    특히 여러 명이 한 브랜치에서 급하게 개발할 땐 git 습관이 불편함으로 다가옴
    기본적으론 편하지만, 복잡한 상황에선 문제가 많음

  • 특이한 상황만 경험해봐도 git의 단점이 보임

• jj를 쓴 지 2주 정도 됐고, 처음으로 커맨드라인만으로 버전 관리를 편하게 쓰고 있음
  git을 쓸 땐 항상 GUI(Git Graph in VSCode)에서 우클릭 위주였는데
  jj는 튜토리얼 만 읽고도 바로 일관된 커맨드라인으로 진입이 가능했음
  다만 jj 로그에서 id를 계속 복붙하는 걸 방지하려면 revset 언어를 배워야 할 듯함

  • 나도 비슷한 상황임
    git을 오래 썼지만 복잡한 건 항상 UI로 처리했었음
    한 달 가까이 jj CLI만 사용 중이고 꽤 만족스러움
    다만 jj 공식 문서가 기본 지식이 있다는 전제로 쓰여 있어서 초보에겐 헷갈릴 때가 있음
    블로그, 튜토리얼이 더 많아지길 바람
    나도 revset 언어랑 rebase 좀 더 배워보고 싶음
    간결한 cli, 충돌 해결, oplog 다 맘에 듦

  • 나도 id 복사 붙여넣기 불편했었는데, jjui(https://github.com/idursun/jjui) 쓰고나선 훨씬 부드러워졌음
    마치 로그를 훑듯이 빠르게 작업하게 됨

• jj 최고의 기능은 undo라고 생각함
  git에서 undo는 실수 종류에 따라 커맨드가 따로 있어서 어려움
  jj는 jj undo 한 번이면 끝남
  백엔드 시스템에도 얽매이지 않아 로컬에서 혼자 jj 써도 동료에게 영향 없음

• jj가 뭔지 혼란스러움
  git 헷갈리는 사람을 위한 프론트엔드인지 궁금함
  백엔드 추상화한다고 하지만 git에 너무 영향을 받아 Perforce, Piper처럼 순차 넘버 커밋이 강제되는 시스템에선 잘 상상이 안 됨
  작업카피=커밋 설계는 퀄리티 컨트롤이 불가하다고 생각함
  커밋의 본래 의미는 꼭 의도된 것만 올리는 것인데, 이런 구조면 "쓰레기 커밋" 구분이 더 어려워짐
  git이나 jj 모두 대형 프로젝트에는 취약하고, 커밋 난립을 방지하지 못하는 점은 고쳐지지 않은 듯함
  jj가 실제로 어떤 문제를 푸는지 궁금함, 단순히 저자 취향의 프론트엔드인지 모르겠음

  • Piper 백엔드는 오히려 Git 백엔드보다 더 자연스럽게 돌아감
    jj 커밋은 git 커밋과 완벽하게 대응하지 않으니, 오해할 필요 없음
    실제로 “커밋”이라 하면 “이름 붙은 diff” 개념이고, 푸시 전 변경은 언제든 쉽게 갈아엎어 정리할 수 있음
    git에서 리베이스, 히스토리 편집보다 훨씬 편함
    나는 실험, 문서 등 여러 커밋을 작업 중간에 만들고, git이었다면 stash나 임시 브랜치에 억지로 넣었어야 했음

  • jj는 git 프론트엔드 이상임
    버전 컨트롤 시스템이고, backend-agnostic함
    대표 backend가 git이라 바로 기존 repo에서 전환 가능함
    나는 git을 github 나오기 전부터 썼던 유저지만, jj 쓰다 다시 git으로 못 돌아가겠음
    jj는 더 단순하면서도 강력함
    working copy=commit은 실제로 “index도 하나의 커밋이다” 식으로 이해해야 함
    예를 들어 feature x 작업 시작시 jj new -m "working on feature x" trunk로 새 커밋 만들고, 그 위에 비어있는 커밋 하나 더 얹음
    작업물은 워킹 카피(@)에 들어가고, 이전 커밋(@-)으로 “옮기기(squash)”해서 git의 add-p, reset 등 복잡한 옵션 대신 커밋 간 diff로 모든 걸 처리함
    이 구조 덕에 git index보다 유연하고 강력하게 커밋을 분할·정리할 수 있음
    커밋 난립 문제는 pull request 문화에 더 가깝고, jj도 일정 부분만 해결해줄 수 있음

  • working copy가 깃허브에 무작정 푸시되는 건 아니고, 커밋 설명 붙일 때 리뷰/정리하면 됨

• jj를 며칠 써봤지만, 기존 lazygit 및 내 워크플로우, 스크립트 셋업에 충분히 만족하고 있음
  jj가 참신하고 괜찮긴 한데, 이제 막 버전 관리 시작하는 입장 아니면 굳이 바꿀 동기가 부족함

  • GitButler처럼 다른 도구 쓰면 프론트엔드가 덜 중요한데, 며칠 전 Jujutsu 도입해서 Claude에게 주요 동작(커밋, 브랜치 이동, 깃허브 푸시/풀) 묻고 10분 만에 숙달됨
    여전히 Lazygit의 diff는 쓰지만 detached HEAD 상태로 있어도 전혀 문제 없음
    JJ는 git과 잘 호환되고, 복잡한 커맨드를 외울 필요 없이 훨씬 쉽게 모든 걸 처리해줌
    브랜치 간 이동 때 미커밋 파일이 자동으로 같이 움직이는 건 최고의 기능임
    개발, 버그 수정, 카피 변경 등 오가며 작업하기 매우 수월함
    AI 에이전트가 변경 작업하면 worktree 분리해 쓰면 됨
    작업 완료 전에 변경 설명(=커밋 메시지) 붙여서 트리에서 미리 볼 수 있는 것도 정말 좋음
    JJ는 전반적으로 상당히 훌륭함