これがあるって今日知った。ありがとう！(ただの一般人、著者じゃないよ)

これはgitには解決策になるかもしれないけど、Review Boardチームが考えたものに見えるし、SVNやCVS、Perforceなどの他の多くのバージョン管理システムと統合しなきゃいけないんだよね。これは多くの異なるバージョン管理システムを一つのフォーマットでサポートするためのものみたいだ。私はReview Boardを使っていたところで働いていたけど、SVNが主なVCSで、多くの開発者がローカルのgit-svnミラーを使っていた。時々、SVNとgit-svnが一つのレビューで混ざると、diffのアップロードに問題が起きた。Review BoardのCLIが両方のために共通のdiffフォーマットを生成してくれたら助かっただろうな。

gitには行単位のdiffよりも細かい単語単位のdiffもあるよ、デフォルトの区切りは空白。

問題の一部は、一般的なフォーマットが人間に読みやすくて、ツールでも解析できる妥協点になってることだと思う。著者がメタデータでその辺を解決しようとしてるのは分かるけど、プレーンテキストに依存しないフォーマットを考える方がいいんじゃないかな。あなたが言ってるようなファイルの合理的な差分を計算する方法を考えるのは難しそうだけど、解決できないわけじゃないと思う。

完全に同意する！構造化データのためのより良い差分表現を探る道はたくさんあると思う（ASTにもいいし、これについても考えてる）。このフォーマットはUnified Diffsの拡張を目指してる（ほとんどのSCMの差分フォーマットみたいに）で、全く新しいものではないんだ。でも、もっと具体的な差分フォーマットが広まれば、DiffX内でそれを直接サポートできるようになるかもね、バイナリ差分フォーマットのように。

初期のドラフトでは、構造に関していくつかのアプローチを試したんだ。「commit-meta」とかね。最終的には、パースの要件を簡素化するために#に分解した。メタブロックはすべてメタブロックで、どのセクションレベルにいるべきかを知って、実際に得られるセクションレベルと比較するのは「点を数える」ことになる。ヘッダーフォーマットは、パーサーが知っている非常にシンプルなキー/バリューのペアを意図していて、自由形式のメタデータではない。それが「メタ」ブロックの役割。ヘッダーのパースルールは意図的にとてもシンプルだ。JSONは、私たちと外部の関係者との間でたくさん議論した結果、他の文法を試した後に選ばれた。メタブロックのヘッダーは、将来的にJSONに代わる何かが意味のある形で登場した場合にデータをシリアライズするためのフォーマットを指定できる。自分たちを縛りたくはなかったけど、どんなフォーマットでも入れられるわけにはいかない（そうすると、今直面しているフォーマットの互換性の頭痛に戻るから）。他のメモについては、1. 互換性はここでの重要な要素だから、基本的なJSONを選びたい。リストの末尾にカンマをつけられるといいけど、JSON5パーサーにアクセスできない人が実装するのを難しくするほどではない。2. もしGNU patch（またはそれに類似したもの）にフィードするのが目的なら、まだ分けられる。この追加データはUnified Diffの「ゴミ」エリアにあるから、どうせ無視される（衝突しない限り、そしてその点についてはエンコーディングの推奨で注意を払ってる）。もしDiffXファイルを2つに分けるのが目的なら、先頭のヘッダーを再追加する必要があるから、もっと複雑になる。ただし、実際に使われているすべての差分フォーマットが分けられて、すべてのメタデータを保持できるわけではない。例えば、Mercurialの差分には、親コミット情報を示すために必ずトップに存在しなければならないヘッダーがある。それを削除してGNU patchにフィードすることはできるけど、Mercurial（またはそのフォーマットをサポートするツール）は親コミットの情報を持たなくなる。3. リビジョンはSCMに大きく依存する。一部のSCMはコミット識別子を使うし、他はファイルごとの識別子を使う。中にはその二つの組み合わせを使うものもあるし、さらに差分に注入されるか、境界外で知られる必要がある追加情報を使うものもある。SCMの世界にはさまざまな要件がある。

これ、Review Boardで使われてるみたいだね。ソースコードレビューに差分をめっちゃ活用してるし、いろんなバージョン管理システムに対応してるんだ。

これについては、コメント一つじゃ収まらないくらい長い話があるんだけど、要はSCMを作る人やSCMと連携するツールを作る人向けだね。エンドユーザーはそんなこと気にしなくていいはず。パッチや差分のフォーマットは一つじゃないし、SCMごとに少なくとも一つはある。いくつかはかなり良い（Gitのやつ）、多くはまあまあ（Subversionのやつ）、そして本当にひどいか存在しないものもある。俺は古いコードレビュー製品の一つ、Review Boardを立ち上げたんだけど（来年で20周年）、この問題に常に取り組んでる。だから、俺たちが文句言ってる側なんだ :) で、これについては、長い間話してきたSCMベンダーからのフィードバックに基づいてる。ほとんどの人は気にしなくていいけど、差分フォーマットの地獄に対処しなきゃいけないツールには役立つ。

difftasticは最高だね！これはファイルやASTの変更を表示するためのツールじゃないんだ。これは、20年以上にわたって差分パースツールを作り、さまざまなSCMと向き合ってきた中で遭遇した問題に対処するための、処理やパッチ作成用の単一の差分ファイルを生成する方法なんだ。エンドユーザー向けのツールではなく、コードレビュー製品のようなツールが使うのに便利なフォーマットだよ。

これ、すごくいいね。diffはCプリプロセッサのブランチでパッチを当てるにはかなり非効率的だよ。コードをパッチするから、ツリー構造を見て、diffは人間が読めるの？直接編集できるの？これが、俺がパッチにはsedを選ぶ大きな理由なんだ。

そうだね、最近はあんまり見かけないけど、俺はまだpatch(1)とかを使うことがあって、時々問題にぶつかることもあるよ。特に、異なるプラットフォームの開発者がいるときはね（ファイル名のマングリングやケースフォールディングの問題については、もう話したくもないよ）。

うちは、十数種類のSCMと連携するコードレビュー製品を作ってるんだ。約20年にわたってdiffパーサーを書いてきたけど、SCMが生成するdiffファイルには、予想もしなかったような問題や制限がいろいろあったよ（それを処理しなきゃいけないからね）。これらは、そこでの痛みや学びから来ていて、解決するのに大きな助けになってるんだ。エンドユーザーが心配する必要はないはずだけど、ツールはこれらの問題を考慮して対処しなきゃいけない。特に、自分のdiffフォーマットを持っていないSCMや、データが欠けているもの（例えば、削除されたファイルはすべての変更に表現できない場合がある）や、リポジトリ内のファイルを特定するのに十分な情報が含まれていないものにとってはね。

一般的に言うと、特定のSCMや特定の環境で使われるSCMと連携するツールを書いていない限り、こういう問題に対処する必要はないと思うよ。各ポイントについていくつか例を挙げるね：1. エンコーディングが重要になるのは、ファイル名とdiffの内容の2つの重要な領域がある。Gitはファイル名のエンコーディングに気を使うけど、ほとんどのSCMはそうじゃないから、diffが生成されるときはローカルエンコーディングに基づいているんだ。ファイル名に非ASCII文字が含まれていると、ある環境で特定のエンコーディングで生成されたdiffが別の環境では適用できないことがある（あるいは、うちの場合のようにリポジトリから見つけられないことがある）。これは一般的ではないけど、起こりうるんだ（PerforceやSubversionで見たことがある）。それから内容の話。多くのSCMは実際にはテキストファイルの表現を提供するだけで、生の内容そのものを提供しないことがある。そのテキストファイルはローカルまたは好みのエンコーディングに再エンコードされ、新しい行も調整されることがある（\r\n、\n）。変更をプッシュするときに、そのテキストファイルは再エンコードされる。これにより、異なる環境で同じファイルを操作できるようになるんだ。ただ、これがdiffに必ずしも反映されるわけではない。だから、あまり一般的でないエンコーディングのdiffをツールに送って処理させて、それをそのエンコーディングでチェックアウトしたファイルに適用しようとすると、パッチが失敗することがある。解決策は、処理しているファイルのエンコーディングを知るか、推測することだよ（うちのようなツールは、試すための好みのエンコーディングのリストを指定できるようになってる）。できれば事前に知っておくのがベストだね。ボーナスの面白い事実：いくつかのSCM（Perforceが思い浮かぶ）では、WindowsでファイルをチェックアウトしてからLinuxで共有マウント経由でdiffを取ると、 \r\r\nの改行を持つdiffが得られることがある。これは厄介で、パッチが壊れる。これがよく起こっていたけど、なんとか対処したよ。また、Perforceはしばらくの間、エンコーディングを誤って正規化することがあって、diffにBOMが入ってしまい、GNU patchが壊れることもあった。2. 直接適用やパッチを行う場合には重要だよ。処理のためにツールに渡すときに、シーケンスの中で一つのファイルが含まれないリスクがあると、後で処理するまで見えないような壊れた状態になることがある。すべての状態やメタデータが事前に揃っていると、一貫した方法で一度に処理できるから、すごく便利なんだ。ローカルで作業する場合も、ツールによるね。git format-patchやgit amは素晴らしいけど、Git専用なんだ。もし（例えば）Subversionで作業しているなら、自分で何かをするか、別のツールを見つける必要がある。3. リポジトリ内のファイルを特定するために必要な情報の種類によっては重要だよ。一部のシステムでは、コミット全体の識別子が必要だし、ファイルごとの識別子が必要なものもある。両方の組み合わせが必要な場合もあるし、パスやリビジョンに表現されない追加データが必要な場合もある（一般的には特定のユースケースをターゲットにしたエンタープライズSCM）。Unified Diffフォーマットに含まれていない情報を表現するためにも重要だよ（具体的にはファイル名以外のもの）。だから、シンボリックリンク情報、ファイルモード、ファイルやディレクトリに関するSCM特有のプロパティなどがある。SCMが提供する情報はどこかに存在する必要があって、どのようにそのデータを保存するかは各SCMの選択に委ねられている（そして、どのようにエンコードするかなどもね）。