Phát hành jj v0.42.0 - Hệ thống quản lý phiên bản tương thích Git

• Chuyển sang bộ cấp phát bộ nhớ mimalloc để cải thiện hiệu năng đa luồng
• Loại bỏ các tùy chọn lệnh dự kiến bị khai tử như jj commit --reset-author/--author, jj describe --no-edit/--edit/--reset-author/--author
• Loại bỏ các tùy chọn jj git push --allow-new, jj metaedit --update-committer-timestamp
• Loại bỏ các tùy chọn cấu hình dự kiến bị khai tử như git.auto-local-bookmark, git.push-new-bookmarks
• jj evolog ngừng hỗ trợ predecessor của commit legacy được ghi trước jj 0.30
• Tự động hoàn tất shell hiển thị mô tả cho alias, revset-alias, template-alias, fileset-alias do người dùng tùy biến, đồng thời trích xuất mô tả từ trường .doc trong định nghĩa alias dạng bảng
• jj show nhận nhiều revision và hiển thị từng revision theo thứ tự, gần với git show hơn
• jj git fetch tạo evolution history dựa trên change ID, và nếu remote giữ nguyên change ID thì sẽ rebase các revision descendant cục bộ lên parent đã được viết lại
• Lệnh jj util backend name xuất ra tên backend commit mà kho hiện tại đang sử dụng
• Thêm cấu hình edit-invocation-mode cho diff editor; khi đặt "file-by-file", trình soạn thảo sẽ được chạy một lần cho mỗi tệp thay đổi, cho phép dùng các công cụ theo từng tệp như vimdiff
• jj git remote add báo lỗi thay vì panic khi tên remote rỗng hoặc chứa khoảng trắng
• Ở trạng thái tắt xuất màu, color-words diff hiển thị before/after trên các dòng riêng để cải thiện khả năng đọc của diff khi dùng pipe hoặc redirect

[GN⁺]

Ý kiến trên Lobste.rs

• Nếu jj git fetch giờ tạo ra lịch sử tiến hóa dựa trên change ID, thì nếu remote giữ nguyên change ID, có phải sẽ không cần chạy jj new main ngay sau mỗi lần jj git fetch nữa không?
  Nếu vậy thì có vẻ là một cải thiện chất lượng trải nghiệm khá tốt

  • Tôi không đọc ra như vậy. Khi fetch thì các change khác với trước sẽ xuất hiện trên main, nên có lẽ chuyện đó không giúp được phần này
  • Nếu thêm trailer vào commit message thì remote nào cũng sẽ giữ lại nó
    Chỉ là tôi không rõ với merge commit do GitHub tạo mà không có change ID thì sẽ thế nào

• Tôi tò mò hơn về đoạn nói rằng đã đổi sang allocator bộ nhớ mimalloc để tăng hiệu năng đa luồng
  Với các tiến trình chạy lâu, tôi từng thử dùng thứ như jemalloc để giảm phân mảnh, nhưng jj có cảm giác khởi động trong 1ms và kết thúc trong vòng 10ms, nên khá bất ngờ khi việc đổi allocator lại tạo ra khác biệt có thể cảm nhận được
  Tìm thêm thì tôi thấy PR là https://github.com/jj-vcs/jj/pull/9484 và chỉ tìm được thêm https://github.com/jj-vcs/jj/issues/2490#issuecomment-2595323515, nhưng không có vẻ là cải thiện tốc độ quá lớn. Dù vậy, nếu nhanh hơn và chỉ cần đổi vài dòng thì cũng ổn

• Có nói là “nếu remote giữ nguyên change ID”, nhưng thường thì tôi không biết remote có giữ nguyên thứ đó hay không
  Tôi biết jj gerrit upload sẽ thêm footer change ID, nhưng jj git push thông thường thì không làm vậy

  • Có thể xem là được giữ nguyên miễn là commit không bị viết lại
    Tuy nhiên, các thao tác viết lại commit như squash merge hay rebase merge của GitHub thì sẽ không giữ lại. Nếu xử lý bằng công cụ chuẩn dựa trên libgit2 thì custom header sẽ không được giữ, còn một số công cụ như thư viện Rust mà GitButler dùng thì có hỗ trợ giữ custom header, nhưng không rõ các forge có dùng mấy thứ đó hay không
  • Tôi muốn biết remote nào giữ nguyên change ID
    Tôi cũng không biết phải kiểm tra thế nào để xác nhận là nó thực sự đang được giữ nguyên
  • Có vẻ change ID được nói ở đây không phải Gerrit change ID mà là jujutsu change ID
    Tài liệu có thông tin chi tiết hơn
  • GitLab có giữ. Công ty tôi hiện đang dùng theo cách đó
    GitHub cũng giữ, có thể kiểm tra qua commit của pushcx trong codebase lobsters hoặc commit của tôi

• Tôi đang tự hỏi liệu có tài liệu nào đáng đọc hoặc xem về lý do nên dùng jj thay cho Git chuẩn không
  Tôi biết jj có thể chạy trên Git và cũng đã thử nghiệm nó trong vài dự án cá nhân, nhưng vẫn chưa thực sự thấy được điểm hấp dẫn mang tính quyết định về việc vì sao nó tốt hơn hoặc dễ hơn