Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
jj(Jujutsu) v0.42.0 릴리스와 관련하여 Git 호환 버전 관리 시스템의 Change ID 보존 여부를 논의합니다. GitLab과 GitHub에서의 동작 차이 및 표준 Git 도구와의 호환성 문제를 다룹니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기“원격이 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 위에서 동작할 수 있다는 건 알고 있고 취미 프로젝트에서 실험도 해봤지만, 왜 더 낫거나 쉬운지에 대한 결정적인 매력을 아직 잘 못 찾겠음