公開：2024年10月7日
1分で読めます
Git 2.47.0の新機能
Gitの最新バージョンについてご紹介します。新たに追加されたグローバル変数を使用すれば、参照やオブジェクトのハッシュの形式を設定できます。GitLabのGitチームと、より広範なGitコミュニティによるコントリビュートをご確認ください。
Gitプロジェクトは、最近Gitバージョン2.47.0をリリースしました。 GitLabのGitチームやより広範なGitコミュニティからのコントリビュートを含む、本リリースの主なハイライトをご覧ください。
新しいグローバル構成オプション
Gitの最新リリースをチェックしている方であれば、Gitバージョン2.45より新たに提供開始された「reftable」参照バックエンドについてご存知かもしれません。詳しくは、『Git reftableフォーマットの入門ガイド』をご確認ください。これまでは、「reftable」フォーマットを使用してリポジトリを初期化するには、次のようにgit-init(1)コマンドに--ref-formatオプションを付けて実行する必要がありました。
$ git init --ref-format reftable
Git 2.47のリリースでは、init.defaultRefFormatという設定オプションが追加され、リポジトリを初期化する際にどの参照バックエンドを使用するかをGitに指示できるようになりました。このオプションを使用することで、デフォルトの「files」バックエンドを上書きし、「reftable」バックエンドを利用できるようになります。設定するには、以下のコマンドを実行します
$ git config set --global init.defaultRefFormat reftable
一部の方はご存知かもしれませんが、Gitリポジトリで使用されるオブジェクトのハッシュ形式も設定可能です。デフォルトでは、リポジトリはSHA-1オブジェクト形式を使用するように初期化されますが、SHA-256形式というより安全で将来性のある代替案もあります。詳しくは、GitalyにおけるSHA-256のサポートに関する過去のブログ記事でご確認いただけます。SHA-256リポジトリは、git-init(1)に--object-formatオプションを指定することで作成できます。
$ git init --object-format sha256
このGitのリリースでは、別の設定オプションとして、init.defaultObjectFormatが追加されました。このオプションは、リポジトリを初期化する際に、どのオブジェクト形式をデフォルトで使用するかをGitに指示するものです。以下のコマンドで設定できます。
$ git config set --global init.defaultObjectFormat sha256
注意点として、SHA-256リポジトリはSHA-1リポジトリと互換性がなく、すべてのフォージがSHA-256リポジトリのホスティングをサポートしているわけではありません。先日GitLabが発表したSHA-256リポジトリの実験的サポートをお試しになれます。
これらのオプションを使うことで、すぐにこれらのリポジトリ機能を使用できるようになり、新しいリポジトリを初期化するたびに形式について検討せずに済みます。
このプロジェクトはPatrick Steinhardtが主導しました。
git-refs(1)のサブコマンド
前回のGitリリースでは、リポジトリ内の参照への低レベルアクセスを可能にするコマンド「git-refs(1)」が導入されました。このコマンドには、参照バックエンド間での変換を行う「migrate」サブコマンドが含まれていました。今回のリリースでは、新たに「verify」サブコマンドが追加され、参照データベースの整合性を確認できるようになりました。リポジトリの整合性を確認する際には、「git-fsck(1)」を実行するケースが多々あります。
しかし、このコマンドはリポジトリの参照データベースを明示的に検証するわけではありません。特に「reftable」というバイナリ形式の参照形式が導入されたことで、手動での検証が難しくなり、このギャップを埋めるツールの必要性が増しています。例として、無効な参照を設定したリポジトリを作成して検証してみましょう。
# The "files" backend is used so we can easily create an invalid reference.
$ git init --ref-format files
$ git commit --allow-empty -m "init"
# A lone '@' is not a valid reference name.
$ cp .git/refs/heads/main .git/refs/heads/@
$ git refs verify
error: refs/heads/@: badRefName: invalid refname format
この例では、無効な参照が検出され、エラーメッセージが表示されていることが確認できます。このツールはエンドユーザーが頻繁に使用するものではありませんが、サーバー側でリポジトリの整合性を保つために特に有用です。最終的には、このコマンドを「git-fsck(1)」に統合し、一貫したリポジトリ整合性チェックを行えるようにすることが目標です。
このプロジェクトは、Google Summer of Code（GSoC）の一環としてJialuo Sheによって主導されました。詳しくは、Jialuoの『GsoCレポート』をご参照ください。
reftableに関連した進行中の作業
今回のリリースでは、「reftable」バックエンドに関するいくつかのバグ修正も含まれています。その中でも特に興味深いのは、テーブルの圧縮プロセスに関するバグです。
ご存知でない方のために説明すると、reftableバックエンドはリポジトリ内のすべての参照の状態を保持する一連のテーブルで構成されています。各参照のアトミックな変更が行われるたびに、新しいテーブルが作成され、「tables.list」ファイルに記録されます。テーブルの数を減らすために、参照の更新後には、テーブルがファイルサイズに基づいた幾何数列に従って圧縮されます。テーブルが圧縮されると、「tables.list」ファイルも更新され、ディスク上のreftableの最新の状態が反映されます。
設計上、テーブルの書き込みと圧縮を同時に実行可能です。特定のタイミングでの同期は、ロックファイルを使用して制御されています。たとえば、圧縮が始まる際には、最初に「tables.list」ファイルが、安定した読み込みのためにロックされます。また、圧縮が必要なテーブルもロックされる場合があります。実際のテーブルの圧縮には時間がかかるため、ロックは途中で解除され、同時書き込みが実行されます。同時書き込みは、ロックされている圧縮対象のテーブルを変更してはいけないことを理解した上で行われるため、この処理は安全です。圧縮された新しいテーブルの書き込みが完了すると、再び「tables.list」ファイルがロックされ、今度は新しいテーブルの状態が反映されるように更新されます。
しかし、次のような問題があります。もし、テーブルの圧縮中に最初のロックが解除された後、リストファイルが更新される前に、参照の同時更新によって新しいテーブルが「tables.list」に書き込まれたらどうなるでしょうか？このような競合が起こると、圧縮プロセスでは新しいテーブルの存在が認識されず、新しいテーブルを反映しないまま「tables.list」ファイルを書き直してしまいます。これにより、同時に行われた更新が失われ、参照が想定どおりに追加、更新、削除されない結果になる可能性があります。
幸い、この問題は比較的簡単な手順で解決できます。圧縮プロセスで「tables.list」ファイルへの書き込みのためにロックが取得される際は、ファイルに更新があったかどうかを最初に確認してから、ファイルを再読み込みする必要があります。これにより、同時に行われたテーブルの更新も正しく反映されるようになります。こちらの修正について詳しくは、該当するメーリングリストのスレッドをご参照ください。
このプロジェクトはPatrick Steinhardtが主導しました。
git-maintenance(1)の修正
リポジトリが大きくなるにつれて、適切なメンテナンスが重要になります。デフォルトでは、Gitは特定のオペレーション後にgit-maintenance(1)を実行することで、リポジトリの健全性を保ちます。その際、不要なメンテナンスが行われないようにするために、--autoオプションが指定されています。このオプションでは、定義されたヒューリスティック（経験則）を使用してメンテナンスタスクを実行するかどうかを決定します。このコマンドは、さまざまなメンテナンスタスクを実行するように設定できますが、デフォルトでは、ユーザーが通常の作業を続けられるように、git-gc(1)のみがバックグラウンドで実行されるようになっています。
この動作は通常、期待どおりに機能しますが、デフォルト以外のメンテナンスタスクを実行するように設定されている場合、設定されたメンテナンスタスクはフォアグラウンドで実行され、最初のメンテナンスプロセスはすべてのタスクが完了するまで終了しません。唯一「gc」タスクだけが期待どおりにバックグラウンドで実行されます。この原因は、git-gc(1)が--autoオプションで実行された際に、誤ってプロセスをデタッチしていたこと、また、ほかのメンテナンスタスクがそのような機能を持っていなかったことであると判明しました。この問題により、一部のGitコマンドが自動メンテナンスの完了を待機する必要があり、コマンドの実行速度が低下する可能性がありました。
今回のリリースでは、git-maintenance(1)に--detachオプションが追加され、個々のタスクではなくgit-maintenance(1)全体のプロセスをバックグラウンドで実行できるようになったことで、この問題が解消されました。また、Gitが実行する自動メンテナンスもこの新しいオプションを使うように更新されています。こちらの修正について詳しくは、メーリングリストのスレッドをご参照ください。
前述したように、自動メンテナンスでは、特定のメンテナンス操作を実行すべきかどうかを判断するために一連のヒューリスティックが使用されます。しかし残念なことに、「files」参照バックエンドでは、git-pack-refs(1)が--autoオプションで実行された場合、このようなヒューリスティックが存在せず、疎な参照が必ず「packed-refs」ファイルにパック化されてしまいます。多くの参照を持つリポジトリでは、「packed-refs」ファイルの書き換えに時間がかかることがあります。
今回のリリースでは、「files」バックエンドで疎な参照をパック化するかどうかを決定するヒューリスティックも導入されました。このヒューリスティックは、既存の「packed-refs」ファイルのサイズとリポジトリ内の疎な参照の数を考慮します。「packed-refs」ファイルが大きくなるほど、参照のパック化が実行される前に許容される疎な参照の数のしきい値も上がります。これにより、「files」バックエンドでの参照のパック化をやや抑制しつつ、適切にリポジトリがメンテナンスされた状態を保てます。詳しくは、メーリングリストのスレッドをご参照ください。
このプロジェクトはPatrick Steinhardtが主導しました。
コードリファクタリングと保守性の向上
機能の変更に加えて、コードリファクタリングやクリーンアップも進められています。これらの改善は、プロジェクトの内部コンポーネントをライブラリ化するという長期的な目標にも寄与するという点でも重要です。ライブラリ化に関する最新のアップデートについては、こちらのスレッドをご参照ください。
メモリリークを解決することも、求められていた改善事項でした。Gitプロジェクトには多くのメモリリークが存在しますが、通常Gitプロセスは短時間しか動作せず、システムによるクリーンアップが後から行われるため、大きな問題が生じることはあまりありません。しかし、ライブラリ化を進める上では、この問題に対処する必要があります。リークサニタイザを使ってプロジェクト内のテストをコンパイルし、リークを検出することはできますが、既存のリークが存在しているために、新しい変更が新たなリークを引き起こしていないかを検証し、それを阻止するのは難しい状況でした。現在、プロジェクト内の既存のテストで検出されたすべてのメモリリークを修正する取り組みが進められています。リークのないテストはTEST_PASSES_SANITIZE_LEAK=trueとマークされ、今後もリークが発生しないことが想定されます。今回のリリース以前は、プロジェクトにメモリリークを含むテストファイルが223件ありましたが、今回のリリースでは60件にまで減少しました。
もう1つの取り組みとして、プロジェクト全体でグローバル変数の使用を減らす作業が進められています。その中でも特に問題視されているのがthe_repositoryというグローバル変数で、これはオペレーション中のリポジトリの状態を保持し、プロジェクト内のさまざまな箇所で参照されています。今回のリリースでは、このthe_repositoryの使用を減らし、必要な場所に直接値を渡すようにするための複数のパッチが導入されました。まだthe_repositoryに依存しているGitプロジェクトのサブシステムでは、このグローバル変数を使用できるようにするためにUSE_THE_REPOSITORY_VARIABLEが定義されています。現在ではrefs、config、pathのサブシステムはこの変数に依存しなくなりました。
このプロジェクトは、John CaiとJeff King氏の協力のもと、Patrick Steinhardtが主導しました。
補足情報
このブログ記事では、GitLabや広範なGitコミュニティによる最新リリースへのコントリビュートの一部をご紹介しました。Gitプロジェクトの公式リリースのお知らせでは、さらに詳しい情報をご覧になれます。また、過去のGitリリースに関するブログ記事では、GitLabチームメンバーによるこれまでの主要なコントリビュートをご紹介しています。