jj v0.43.0 공개

 (github.com/jj-vcs)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Git 호환 버전 관리 시스템 jj v0.43.0은 여러 변경 집합을 대상으로 명령을 실행하는 jj run을 추가해 반복 검증·수정 작업을 더 자동화할 수 있게 함
  • jj run은 변경 집합마다 전용 작업 복사본을 쓰며, cargo check나 cargo fix처럼 작업 복사본을 바꾸는 명령의 변경 사항과 충돌도 전파함
  • 이번 릴리스는 git_head(), git_refs(), Git식 심볼 해석, ui.revsets-use-glob-by-default 제거 등 기존 설정·revset 사용 방식에 영향을 주는 변경을 포함함
  • jj show --reversed, /etc/jj 설정 탐색, jj config gc, jj gerrit upload -o, forks() revset 함수, 취소선 색상 스타일도 추가됨
  • Windows 파일 identity 처리, 불변 작업 복사본 스냅샷, 중복 remote URL 경고, Intel Raptor Lake 및 aarch64의 loose Git object 손상 문제가 수정됨

릴리스 개요

  • jj는 단순하면서도 강력한 Git 호환 버전 관리 시스템임
  • v0.43.0에서는 여러 변경 집합에 명령을 적용하는 jj run이 새로 추가됨
  • 시작을 위한 설치 안내는 installation instructions에서 확인할 수 있음

변경 집합별 명령 실행: jj run

  • jj run은 여러 변경 집합을 대상으로 같은 명령을 실행할 수 있음
  • 각 변경 집합은 서로 분리된 전용 작업 복사본을 사용함
  • 실행된 명령이 작업 복사본을 업데이트할 수 있으며, 그 결과로 생긴 변경 사항과 충돌은 알맞게 전파됨
  • 사용 예시는 다음과 같음
    • jj run -- cargo check --all-features
    • jj run -- cargo fix

호환성에 영향을 주는 제거 사항

  • revset과 template에서 더 이상 사용되지 않던 git_head() 및 git_refs() 함수가 제거됨
  • refs/heads/main 같은 Git식 심볼은 더 이상 리비전으로 해석되지 않음
    • 대신 bookmark/tag의 <name> 또는 <name>@<remote> 문법을 사용해야 함
  • 더 이상 사용되지 않던 ui.revsets-use-glob-by-default 옵션도 사라짐
  • jj bookmark track 및 untrack은 <kind>:<bookmark>@<remote> 패턴을 더 이상 지원하지 않음
    • <bookmark>@<remote> 심볼 문법은 계속 지원됨
    • 관련 이슈: #9226

새로 추가된 기능

  • jj show가 --reversed 플래그를 지원함
  • jj가 /etc/jj에서도 설정 파일을 찾음
  • jj config gc는 ~/.config/jj/repos 폴더에서 삭제되었거나 이동된 저장소의 설정을 정리함
  • jj gerrit upload가 git push -o 또는 --push-option처럼 동작하는 -o / --option 플래그를 지원함
  • jj git fetch는 변경 ID를 기준으로 다시 작성된 리비전의 하위 리비전을 리베이스함
    • 이전에는 스택에 bookmark가 붙은 리비전이 여러 개 있을 때, 다시 작성된 리비전과 그 하위 리비전이 항상 리베이스되지는 않았음
    • 불변 하위 리비전은 리베이스되지 않음
  • forks() revset 함수가 추가됨
    • 자식이 2개 이상인 모든 커밋을 반환함
  • colors 설정이 { crossed-out = true }로 취소선 텍스트 스타일을 지원함

수정된 문제

  • Windows에서 경로의 파일 identity를 조회할 때 더 이상 심볼릭 링크를 따라가지 않음
    • Unix 동작과 맞춰짐
    • 이전에는 같은 대상에 연결된 두 심볼릭 링크가 같은 파일로 취급됐음
    • 이 identity 검사는 작업 복사본을 쓸 때 예약된 .git 및 .jj 디렉터리의 alias를 감지하는 데 사용됨
    • 관련 이슈: #8924
  • 작업 복사본이 불변 상태였을 때, jj가 스냅샷 중 새 working-copy 리비전을 생성함
    • 이전에는 작업 복사본이 불변이 된 직후 새 리비전이 생성됐음
    • 관련 이슈: #7751, #9338
  • jj git remote add는 새 remote의 fetch URL 또는 effective push URL이 기존 remote와 정확히 같으면 경고함
    • 관련 이슈: #413
  • Intel Raptor Lake CPU와 aarch64에서 손상된 loose Git object 문제가 수정됨
    • 이전에는 jj가 커밋 성공을 보고했지만 이후 git fsck가 incorrect data check, corrupt loose object, missing blob로 실패할 수 있었음
    • 이후 jj 작업도 corrupt deflate stream으로 실패할 수 있었음

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • jj run이 아주 기대됨

  • jj bookmark track/untrack <name>@<remote>의 지원 중단이 철회되어서 반가움
    --remote를 매번 치는 건 늘 별로였음

  • Intel Raptor Lake CPU와 aarch64에서 손상된 loose Git 객체를 고쳤다는 부분이 흥미로운 버그처럼 들림
    관련 블로그 글이 나오면 읽어보고 싶음 😃

  • 지금까지 봤던 손상된 Git 객체는 전부 파일시스템 롤백 탓이라고 생각했음
    하드 종료 뒤 f2fs 롤백이 꽤 흥미로운 디스크 상태를 만들곤 했는데, 그냥 그쪽에 깨진 부분이 있었다는 걸 알게 되어 매우 흥미로움

  • jj run이 jj fix와 어떻게 다른지 궁금함
    변경 로그 예시에서도 jj run으로 cargo fix를 실행하던데, 둘이 확실히 겹치는 것 같음

    • jj run은 전체 작업 사본을 만들어서 그 안에서 명령을 실행함
      jj fix는 단일 파일 내용을 명령에 파이프로 넘기고, 출력 결과를 그 파일의 새 내용으로 삼음
      도구가 jj fix와 잘 맞는다면, 보통 포매터나 린터처럼, 훨씬 빠르지만 jj run이 더 유연함
    • 이해하기로는 run은 각 변경마다 명령을 실행하고, fix는 각 변경 파일에 필터를 돌림
      내 경우에는 run으로 테스트 스위트를 돌려 각 커밋이 유효한지 확인하고, 그다음 fix로 파일에 포매터를 돌리는 식이 됨
      아직 업데이트하지는 않았고, 이건 내 해석일 뿐임

  • jj run을 조금 만져보긴 하겠지만, 내가 direnv를 쓰는 방식 때문에 필요 이상으로 까다로워질 가능성이 크다고 봄

답변달기