Git은 괜찮지 않다

글에서 제기한 문제를 jj가 어떻게 해결하는지 보여줬으면 좋았을 듯함
jj 사용자에게는 뻔하겠지만, 그 사람들이 글의 주 대상은 아닐 가능성이 큼

글에서 Git이 괜찮지 않다는 근거로 든 기능들이 개인적으로는 필요했던 적이 없음
나만 그런 건가 싶음

전혀 혼자가 아님
도구에서 중요한 점 중 하나는 도구가 동적인 시스템의 일부라는 것임. 도구가 가능하게 해주는 일이 “내가 할 수 있다고 믿는 일”에 영향을 주고, 그 믿음이 다시 도구에 대한 인식과 도구의 진화 방향을 바꿈
어떤 도구가 기존 상태를 흔들면, 할 수 있는 일에 대한 믿음과 기대치도 같이 바뀜

흥미로워 보이지만 다이어그램을 보면 어지러움

2000년대 초반처럼 지금이 심각하진 않고, Git 이전 버전 관리 시스템의 한계는 꽤 명확했다는 말에 대해, Darcs는 Git보다 먼저 나왔고 스냅샷 기반 버전 관리의 일부 문제를 근본적으로 고친 면이 있었음
초기에 성능이 나빠 밀렸지만 이후 성능은 개선됐고, 사람들이 다시 확인하러 돌아오지 않았음. 흥미로운 일을 하는 다른 버전 관리 시스템도 있으니 “Git이 아니면 Jujutsu”만 유일한 선택지처럼 다루지는 않았으면 함. 그런 식의 논리를 너무 자주 봄

글쓴이가 Git의 데이터 모델은 매우 좋다고 말해놓고, Git의 브랜치가 단지 브랜치 끝을 가리키는 포인터라서 작업 흐름이 좋지 않다고 지나가듯 말하는 게 좀 웃김
그것도 데이터 모델 문제임

jj new A B를 쓰면 작업 복사본 커밋이 여러 부모를 가질 수 있어서, 병합 커밋처럼 동작함
그래서 작업 복사본에 두 부모의 변경이 모두 들어오고, 그 병합 위에서 작업을 이어가거나 어느 한쪽 커밋에 amend하는 식으로 진행할 수 있음

아직은 Git을 더 선호하고, 글쓴이에게는 편향이 있어 보임

Git을 선호하는 이유가 글쓴이가 Git에서 어렵다고 말한 상황을 겪지 않고 이미 Git에 익숙해서인지, 아니면 그런 상황을 겪더라도 Git이 Jujutsu보다 더 나은 작업 흐름을 제공한다고 생각해서인지가 궁금함

jj new를 실행해야 한다는 점만 기억하면 git과 jj를 섞어 쓸 수 있음
Git은 항상 부모 커밋을 가리키고, 현재 jj commit은 작업 트리의 커밋되지 않은 변경처럼 보게 됨
나는 그렇게 jj를 배웠음. 리베이스 처리나 트리 이동처럼 jj가 잘하는 일에는 jj를 쓰고, 아직 jj 대응 명령을 모르거나 git blame처럼 Git 명령이 먼저 떠오르는 일상 작업에는 계속 git 명령을 썼음
실제로 매일 써보기 전까지는 jj가 왜 더 나은지 잘 와닿지 않았고, 읽기만 했을 때는 “이 기능이 꼭 필요할까” 또는 “Git으로도 이미 할 수 있는데”라고 생각했음
물론 jj에도 단점은 있음. 최신 .gitignore가 없으면 바이너리 파일이 실수로 커밋에 들어갈 수 있음. 다행히 아주 큰 파일을 추가하려 하면 jj가 경고하지만, 작은 파일은 빠져나갈 수 있음
디버깅 중 현재 디렉터리에 추적 파일이나 로그 파일이 있으면 그것도 들어갈 수 있으니, 트리를 다 조작한 뒤에는 diffstat을 모두 검토하는 게 좋음
특히 jj로 이진 탐색을 하다가 .gitignore를 갱신한 커밋보다 이전 커밋을 테스트하게 되면 문제가 될 수 있음. 이진 탐색에는 읽기 전용 모드가 있어야 할지도 모름