法律はGitというよりPijul
下の記事では法令の変遷をバージョン管理システム上で機械可読な形式で管理することを提案しています．
提案については賛成するのですが，技術的な点についてコメントをします．
note.com
リンク先の記事では法改正を行う法律は元の法律に対する差分として記述されている，ということを紹介しています．
その上で改正を行う法律のことをGitのコミットと同一視していますが，これは正確ではありません．
なぜならば，Gitのコミットはファイルの差分ではなくスナップショットとしてファイル全体を保存しているからです．
git cat-fileコマンドを使うとスナップショットを確認することができます（詳しくはGit公式の解説が良いです）．
つまり，Gitのコミットは法律の改正が「溶け込んだ」後の現行法の条文を保存していると言えます．
git show等で差分が表示されるのはその時その時にスナップショット間の差分を計算しなおしているからです*1．
一方，差分（パッチと呼びます）をコミットとして保存するバージョン管理システムはパッチベースであるといわれます．
パッチベースのバージョン管理システムとしてはDarcsやPijulが有名です．
これらのシステムにおいてリポジトリの状態（「ブランチ」）はパッチの集合として表現されます．
例えば，Gitで過去に適用したパッチを打ち消す場合はリバートコミットを現在のブランチの上に適用する必要があります．
反対にDarcsやPijulの場合，現在のブランチを表すパッチ集合からリバートしたいパッチを削除するだけで変更を指し戻せます．シンプルだとは思いませんか？
マージコンフリクトの取り扱いも考えてみると面白いでしょう．
Gitにおいてマージは複数のコミットを親とするマージコミットを作成することで行われます．
親コミットの変更がコンフリクトした場合は手でコンフリクトを解消するまでマージは完了せず，その他の処理を行うことはできません．
パッチベースなシステムの場合，マージは常に実行できます．なぜならば，ブランチのマージは単にパッチ集合の和をとるに過ぎないからです．
これはコンフリクトが発生しないということを意味するわけではありません．むしろ，コンフリクトが正常系として組み込まれているといえます．
コンフリクト検知が可能なエディタを用いれば，コンフリクト下においても編集を続けつつ適当なタイミングでコンフリクトを解消するということも難しくないでしょう．
現時点ではGitがバージョン管理システムの中でも独占的な地位を築いています．
ですが，天下もいつまでも続くとは限りません．そのとき台頭してくるのはパッチベースなバージョン管理システムかもしれませんね．
