jj v0.42.0 リリース - Git互換バージョン管理システム

 (github.com/jj-vcs)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 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" を指定すると変更ファイルごとにエディタを1回ずつ実行して vimdiff のようなファイル単位ツールを利用可能
  • jj git remote add が空のリモート名や空白を含むリモート名に対して panic ではなくエラーを報告
  • 色付き出力が無効な状態の color-words diff が before/after を別々の行で表示し、パイプやリダイレクトされた diff の可読性を改善

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rsの意見

  • jj git fetch が今後 change IDベースの進化履歴 を生成するなら、リモートが change ID を保持する場合、毎回 jj git fetch の直後に jj new main をしなくてもよくなるのか気になる
    そうならかなり良い QoL 改善に見える

    • そうは読めない。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 の上で動かせることは知っているし、趣味のプロジェクトで試したこともあるが、なぜより良いのか、あるいはより簡単なのかという決定的な魅力がまだよく分からない