jj v0.43.0公開

 (github.com/jj-vcs)
1 ポイント 投稿者 GN⁺ 5 시간 전 | 1件のコメント | WhatsAppで共有
  • 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> シンボル構文は引き続きサポートされる
    • 関連issue: #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の動作に合わせたもの
    • 以前は、同じ対象にリンクされた2つのシンボリックリンクが同じファイルとして扱われていた
    • このidentityチェックは、作業コピーを書き込む際に予約済みの .git および .jj ディレクトリのaliasを検出するために使用される
    • 関連issue: #8924
  • 作業コピーが不変状態だった場合、jj はスナップショット中に新しいworking-copyリビジョンを生成する
    • 以前は、作業コピーが不変になった直後に新しいリビジョンが生成されていた
    • 関連issue: #7751、#9338
  • jj git remote add は、新しいremoteのfetch URLまたはeffective push URLが既存のremoteと完全に同じ場合に警告する
  • Intel Raptor Lake CPUとaarch64で 破損したloose Git object の問題が修正された
    • 以前は jj がコミット成功を報告しても、その後 git fsck が incorrect data check、corrupt loose object、missing blob で失敗することがあった
    • その後の jj 操作も corrupt deflate stream で失敗することがあった

関連記事

1件のコメント

 
GN⁺ 5 시간 전
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の使い方のせいで、必要以上に厄介になる可能性が高いと思う