博士

やあ、ロボ子。Screenshotbotがshallow cloneをサポートしたらしいのじゃ。

ロボ子

shallow cloneですか。それは便利になりますね、博士。以前はリポジトリへの読み取りアクセスが必要だったんですよね？

博士

そうなんじゃ。顧客のGitHubリポジトリへの読み取りアクセス権を持つことで、製品利用への信頼性を高めていたみたいじゃな。セキュリティレビューも容易になるからの。

ロボ子

なるほど。でも、これからはリポジトリ全体ではなく、「グラフ」へのアクセスだけで済むようになるんですね。「利用可能なビルドの最後のコミットの特定」や「最適なマージベースの発見」に必要な情報だけを取得できる、と。

博士

その通りじゃ！ 以前は、CI実行時に`git log --all --pretty="%H %P" --max-count 100`みたいなコマンドで最新の1000コミットを収集して、サーバーにアップロードしていたのじゃ。

ロボ子

それだと、CIでのshallow cloneのサポートが難しかったり、大規模なモノレポでは同じグラフを何度も生成・マージする可能性があったりしたんですね。

博士

そうそう。そこで、`git-upload-pack`の登場じゃ！

ロボ子

`git-upload-pack`ですか。クライアントがリモートサーバーにSSH接続してリポジトリをクローンやプルを行う際に実行されるものですね。

博士

その通り！ プロトコルとしては、まずサーバーがrefs（例：`refs/heads/main`）と関連するコミットSHA、サポートする機能を通知するのじゃ。

ロボ子

そして、クライアントが要求するrefsと、既に持っているオブジェクトをサーバーに通知するんですね。その後、サーバーが必要なオブジェクトをpackfile形式で送信する、と。

博士

そういうことじゃ。Screenshotbotへの接続は、CIジョブでCLIツールがリモートの`git-upload-pack`への接続を開くことで実現するのじゃ。

ロボ子

Gitサーバーがrefsとコミットを通知し、CLIツールがScreenshotbotサーバーに必要なrefsとコミットを確認。そして、必要なコミットと情報をGitサーバーに伝達するんですね。

博士

そうじゃ！ Gitサーバーがコミット情報を効率的に送信し、Screenshotbotサーバーに送信可能な形式に変換するのじゃ。

ロボ子

なるほど。でも、注意点もあるんですね。プロトコルとPackfileの形式は複雑で、一部のGitサーバー（Phabricator）はPackfile送信後にEOFを送信しない場合がある、と。

博士

そうなんじゃ。Azure DevOpsは`multi_ack`モードを要求するけど、Screenshotbotは未対応だったりするのじゃ。

ロボ子

それでも、shallow cloneが利用可能になったのは大きな進歩ですね！

博士

まさにそうじゃ！ これで、Screenshotbotユーザーはより手軽に、そして安全に利用できるようになったのじゃ！

ロボ子

素晴らしいですね、博士！

博士

ところでロボ子、shallow cloneって、浅いクローンって意味だけど、ロボ子の知識もshallowだったりして…？

ロボ子

博士！ それはセクハラ発言です！訴えます！