まさに気付いたことだが； アカウントデータベース - (新) 檜山正幸のキマイラ飼育記 メモ編 で、アカウントは、二部グラフの有向辺として定式化できると書いたが、gitの構造もグラフ構造で定式化できるだろう。
git自体のグラフ的解釈は、本編 もうGitは怖くない： 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog) で行っている。このときのグラフはgitオブジェクトをノードとするグラフだった。git remote を使うと、インタネットに散在したリポジトリ達をノードとするグラフができる。
git remote add で、ローカル → リモート 方向の有向辺が生成される。origin などの名前は、辺ラベルになる。辺を記述するデータは、ローカル側に置かれる。非参照側（リモート）は、自分がどこから参照されているかを知らない（バックリンク無しリンク）。git remote add は、自分以外のリポジトリに対して、ローカルな（自分からの）呼び名を付けていることになる。
リポジトリごとに参照ラベル（HEAD、タグ、ブランチなど）があり、これはローカル名。他のリポジトリのラベルは、〈他のリポジトリの短縮名〉/参照ラベル名 の形式で書く。例えば、origin/main など。自分の参照ラベル名は、接頭辞なしの main など。
オブジェクトグラフがコンフリクトすることは原理的にあり得ない。異なる変更には、異なるオブジェクトIDが付くのだから。コンフリクトと言っているのは参照システム側の問題。
リポジトリを主体〈エージェント〉と考えると、その識別子とクレデンシャルが問題になる。httpsで通信するときは：
- リポジトリの識別子は、httpsスキームのURL
- リポジトリのクレデンシャルは、URL自体がクレデンシャル
リポジトリ間リンクに沿った通信では認証が行われるが、認証はリポジトリ間ではなくて、ローカルリポジトリのオーナーであるユーザーと、リモートリポジトリをホスティングしているサービスの間の認証になる。ユーザーが当該のリポジトリへのアクセス権限を持つかどうかは認可構造の問題になる。
リポジトリ間リンクは意味的な構造だが、ユーザーとサービス間の認証・認可は別な構造になる。認可構造には次が関わる。
- オーナーシップ
- パーミッション
- ロール
- アクセス権限指定
- オペレーション〈アクション〉
