テキストツール

2つのテキストを比較する作業は、誰もが日常的に行うものであり、ほぼ必ず最悪のタイミングで発生します。あるホストでは動き別のホストでは動かない設定ファイル、デプロイの間に変わったレスポンスボディ、変更履歴を残さずに誰かが編集した契約書の条項、昨日のものとそっくりだが少しだけ違うログの1行。

目で見て探したくなります。3行ならそれでも通じますが、30行では静かに失敗します。人間の注意力は、期待するものを見つけることにおいて極めて優れているからです。この状況でdiffは便利機能ではありません。変更を見つけることと、変更などなかったと自分を納得させることの分かれ目です。

diffツールの良し悪しを分けるのは粒度です。行単位の比較が正しいデフォルトであり、バージョン管理で表示されるのもそれですが、2種類の入力ではむしろ誤解を招きます。1つは最小化されたファイルや1行ファイルで、文書全体が1行になるため、diffは「この行が変わった」と退化します。もう1つは長い文章行で、1語の編集が段落全体の書き換えとして表示されます。単語モードと文字モードはまさにこのためのもので、貼り付け直さずに3つのモードを切り替えられることこそが価値の大部分です。

もう半分は、出力が持ち運べることです。見るだけのdiffは、人に渡せるdiffより価値が下がります。そこでunifiedパッチの出力は、正しいhunkヘッダーを持つ標準的なパッチを生成します。patch(1)が受け付ける形式であり、コメントに貼り付ければコードレビューツールが正しく表示する形式です。

テキストは、このサイトで扱うものの中でも特にセンシティブになりがちです。JSONのペイロードはたいてい機械向けのデータですが、テキストのdiffは契約書の草稿、社内メモ、インシデントのタイムライン、顧客へのメールであることがよくあります。比較をサーバーではなくブラウザ内で行うのはこれが理由です。機能として謳うためではなく、ローカルで答えられる質問のためにその種の資料を知らないホストにアップロードするのは、いくら安くても割に合わない取引だからです。

比較対象が文章ではなくJSONであれば、代わりにJSON差分比較を使ってください。テキストではなく解析後の構造を比較するため、整形のし直しやキーの順序変更は、テキストdiffなら何百もの変更として報告されるものが、まったくの変更なしとして正しく表示されます。