私は現在、あなたが質問で説明したのと同じ問題の解決策を探しています. ただし、私の会社では、これらのマージ競合を整理するために RSA 自体が使用されています。したがって、正規化された XML ファイルを操作できないマージ ツールまたはエディターを使用している場合、以下で提案するソリューションは完全には機能しません。Gerrit を使用してコードをレビューしているため、同じ問題が発生します。質問で述べたように、ソース コードは人間が読めるものではないため、Gerrit UI 内でレビューまたはコメントすることはできません。
.efx および .emx ファイル名拡張子を持つ XML ドキュメントに埋め込まれたソース コードは、改行、引用符などの文字が対応する HTML エンコード シーケンスに置き換えられるように、変更または正規化されています。Git と Gerrit は、各ソース コード行が改行で終了することを想定しているため、結果は、HTML エンコーディング シーケンスが散在する、いわゆるフラグメント連結のすべてのソース コード行で構成されるほぼ無限に長い行になります。
私たちの会社の誰かが、少なくとも大雑把な diff フィルターを git に追加して、「git show」、「git diff」、およびその他のコマンドを呼び出してファイルの内容を表示したときに、埋め込まれたソース コード行が人間が読めるようにしています。フィルタは、HTML でエンコードされたシーケンスを対応する UTF-8 文字に置き換えるグローバルな検索および置換ステートメントの集まりです。
これに対処するには、基本的に 2 つの選択肢があると思います。
1) 前述の git の diff フィルターとほとんど同じように機能する何らかのフィルターを Gerrit に追加し、HTML エンコーディング シーケンスを対応する UTF-8 文字に置き換えます。
2) smudge および clean フィルターを git に追加して、コードをチェックインするときに、HTML エンコードされた行に隣接して配置された HTML コメント内でソース コード行が UTF-8 に変換されるようにします。Gerrit では、作成者が意図したとおりにソース コードを表示できるため、通常どおりレビューやコメントを行うことができます。チェックアウト時に、smudge フィルターは HTML コメントとその中のソース コードを削除し、.efx と .emx は、RSA がコンテンツをディスクに書き込んだときとまったく同じように見えます。ソース コードが繰り返されるため、これによりファイルの内容が変更され、実質的にサイズが 2 倍になりますが、たとえ HTML コメントがスマッジ プロセスを生き延びたとしても、内容は RSA に影響を与えない有効な XML ドキュメントのままです。
最近、RSA の最新バージョンである 9.1 は、フラグメント ファイルに埋め込まれたソース コードを多かれ少なかれそのまま残すように構成できると聞いたので、リストされているような回避策を必要とせずに Gerrit でレビューおよび検査できます。その上。これが実際に説明どおりに機能するかどうかは、まだ確認していません。