Git 2.48はMesonビルドシステム、既存のMakefile、Autoconf、CMakeベースのシステムに代わる近代的な選択肢をサポートするようになった。この変更は、IDE サポートの制限や古いシステムのメンテナンス問題に対処するものだ。
GitLabのGitエキスパート Christian Couder氏によると、MesonはGit 2.48以前のビルドシステムと比較していくつかの重要な利点を提供する。これにはユーザーフレンドリーな構文、広範な互換性、近代的な機能のサポート、ビルドオプションへの容易なアクセスが含まれる。Mesonのビルドプロセスはビルドディレクトリのセットアップ、コンパイル、テスト、簡単なコマンドを使用したインストールを含む。
Git 2.48は大きなマイルストーンを達成した：テストスイートで検証の結果、メモリリークがなくなっていた。以前は223個のテストファイルにメモリリークがあったが、Git 2.47では60個に減少し、現在は解決されている。この成果はGitの内部コンポーネントを「ライブラリ化」し(ライブラリへ変換する)、メモリ使用を最適化するという目標に沿ったものだ。例外的な理由がない限り、新しいテストはデフォルトでリークフリーでなければならない。
通常のフェッチと同様に、バンドルURIを使ったフェッチもfsckメカニズムを使って包括的な検証を受けられるようになった。この機能強化により問題の受け入れまたは拒否を、重大度レベルに基づいてきめ細かく制御できるようになる。以前はバンドルフェッチには利用できなかったこの機能は、リポジトリの安全性と使いやすさを向上させる。
Git 2.48では、リファレンスの一貫性チェックの作業がさらに進展した。git-fsckコマンドは無効なリファレンスコンテンツや存在しないターゲットを指すシンボリックリファレンスなどの問題を検出可能になった。これらのチェックは、Google Summer of Code（GSoC）2024の一環として開発された後、git-fsckに統合された。
LobsterとRedditの技術コミュニティは、この発表について議論し、意見を交換した。Lobstersの会話スレッドではGitとGitHubが既知の脆弱性にもかかわらずSHA-1に依存していることが指摘された。Gitには安全対策が含まれているが、相互運用性の問題や衝突検出メカニズムのアクシデント的なトリガリングの可能性について懸念が存在する。
さらに、Git 2.45でリファレンス（ブランチやタグなど）を保存するバックエンドとして導入されたReftablesは、イテレータ再利用によりパフォーマンスが向上した。以前はリファレンスを読み取るたびに新しいイテレータを作成する必要があり、繰り返しの読み取りには非効率的だった。現在では、単一のイテレータを複数の読み取りに再利用できるため、ランダム読み取りを伴うトランザクション中のリファレンス作成が7%高速化され、イテレータ内の状態をさらに再利用することでさらなる最適化が期待されている。
Git 2.48では、git refs migrateコマンドを使用してバックエンド間でreflogを移行するサポートも追加された。以前は、Git 2.46で導入された移行作業では、ファイルベースとreftablesのバックエンド間でreflogを変換できなかった。このツールは依然として複数のワークツリーを持つリポジトリを処理できないが、リポジトリでreftablesを採用するユーザーにとってクリティカルな制限を取り除く。
git branch、git tag、git for-each-refなどのコマンドで使われるref-filterサブシステムは、リポジトリ内の大量のリファレンスを処理する際のパフォーマンスを向上させるために最適化された。
公式発表ブログでは、多くの貢献者の努力がハイライトされており、貢献者全員のリストがプロジェクトリリースノートに掲載されている。
作者について
