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

> Clean Markdown view of GeekNews topic #30203. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30203](https://news.hada.io/topic?id=30203)
- GeekNews Markdown: [https://news.hada.io/topic/30203.md](https://news.hada.io/topic/30203.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-05T18:00:54+09:00
- Updated: 2026-06-05T18:00:54+09:00
- Original source: [github.com/jj-vcs](https://github.com/jj-vcs/jj/releases/tag/v0.42.0)
- Points: 1
- Comments: 1

## Topic Body

- **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 가독성 개선

## Comments



### Comment 58983

- Author: neo
- Created: 2026-06-05T18:00:55+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/jqkedb/jujutsu_v0_42_0_released) 
- `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**를 뜻하는 것으로 보임  
    [문서에 더 자세한 정보가 있음](https://www.jj-vcs.dev/latest/git-compatibility/#format-mapping-details)
  - GitLab은 보존함. 지금 회사에서 그렇게 쓰고 있음  
    GitHub도 보존하며, lobsters 코드베이스의 pushcx 커밋이나 내 커밋을 보면 확인 가능함

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