jj v0.42.0 릴리스 - Git 호환 버전 관리 시스템

• mimalloc 메모리 할당자로 전환해 멀티스레드 성능 개선
• jj commit --reset-author/--author, jj describe --no-edit/--edit/--reset-author/--author 등 폐기 예정 명령 옵션 제거
• jj git push --allow-new, jj metaedit --update-committer-timestamp 옵션 제거
• git.auto-local-bookmark, git.push-new-bookmarks 등 폐기 예정 설정 옵션 제거
• jj evolog가 jj 0.30 이전에 기록된 레거시 커밋 predecessor 지원 중단
• 셸 자동완성이 사용자 정의 alias, revset-alias, template-alias, fileset-alias의 설명을 표시하며, 테이블형 alias 정의의 .doc 필드에서 설명 추출
• jj show가 여러 리비전을 받아 git show에 더 가깝게 각 리비전을 순서대로 표시
• jj git fetch가 change ID 기반 evolution history를 생성하며, 원격이 change ID를 보존하면 로컬 descendant 리비전을 다시 작성된 부모 위로 rebase
• jj util backend name 명령이 현재 저장소에서 사용하는 커밋 백엔드 이름 출력
• diff editor용 edit-invocation-mode 설정 추가로 "file-by-file" 지정 시 변경 파일마다 편집기를 한 번씩 실행해 vimdiff 같은 파일 단위 도구 사용 가능
• jj git remote add가 빈 원격 이름이나 공백 포함 원격 이름에서 panic 대신 오류 보고
• 색상 출력이 꺼진 상태의 color-words diff가 before/after를 별도 줄로 보여 파이프나 리다이렉션된 diff 가독성 개선

[GN⁺]

Lobste.rs 의견들

• jj git fetch가 이제 change ID 기반 진화 이력을 생성한다면, 원격이 change ID를 보존하는 경우 매번 jj git fetch 직후 jj new main을 하지 않아도 되는 건지 궁금함
  그렇다면 꽤 좋은 삶의 질 개선으로 보임

  • 그렇게 읽히지는 않음. fetch하면 이전과 다른 change가 main에 생길 테니, 그 부분에는 도움이 안 될 듯함
  • 커밋 메시지에 trailer를 추가하면 어떤 원격도 그걸 보존함
    다만 change ID가 없는 GitHub 생성 병합 커밋에서는 어떻게 되는지 모르겠음

• mimalloc 메모리 할당자로 바꿔 멀티스레드 성능을 높였다는 부분이 더 궁금함
  장기 실행 프로세스에서는 단편화 완화를 위해 jemalloc 같은 걸 써본 적이 있지만, jj는 1ms에 시작해서 10ms 안에 끝나는 느낌이라 할당자 변경이 체감될 정도라는 게 의외임
  추가로 찾아보니 PR은 https://github.com/jj-vcs/jj/pull/9484 이고, https://github.com/jj-vcs/jj/issues/2490#issuecomment-2595323515 정도만 찾았는데 큰 속도 향상처럼 보이진 않음. 그래도 더 빠르고 변경도 몇 줄이면 된다면 괜찮음

• “원격이 change ID를 보존한다면”이라고 했는데, 보통 원격이 그걸 보존하는지 모르겠음
  jj gerrit upload가 change ID footer를 추가하는 건 알지만, 일반 jj git push는 그러지 않음

  • 커밋이 다시 작성되지 않는 한 보존된다고 봐도 됨
    다만 GitHub의 squash merge나 rebase merge처럼 커밋을 다시 쓰는 작업은 보존하지 않음. 표준 libgit2 기반 도구로 처리하면 custom header가 보존되지 않고, GitButler가 쓰는 Rust 라이브러리 같은 일부 도구는 custom header 보존을 지원하지만 forge들이 그런 걸 쓰고 있을지는 의문임
  • 어떤 원격이 change ID를 보존하는지 궁금함
    제대로 보존되고 있는지 어떻게 확인해야 하는지도 모르겠음
  • 여기서 말하는 change ID는 Gerrit change ID가 아니라 jujutsu change ID를 뜻하는 것으로 보임
    문서에 더 자세한 정보가 있음
  • GitLab은 보존함. 지금 회사에서 그렇게 쓰고 있음
    GitHub도 보존하며, lobsters 코드베이스의 pushcx 커밋이나 내 커밋을 보면 확인 가능함

• 표준 Git 대신 jj를 써야 하는 이유를 읽거나 볼 만한 자료가 있을까 궁금함
  jj가 Git 위에서 동작할 수 있다는 건 알고 있고 취미 프로젝트에서 실험도 해봤지만, 왜 더 낫거나 쉬운지에 대한 결정적인 매력을 아직 잘 못 찾겠음