Gitはスマートで、履歴の変更を「追跡」して、マージを簡単にし、自動マージをより簡単にします。競合は、変更の前後で変更されていない線で示されます。K＆Rを使用すると、B＆Dの場合のように、「{」のみが含まれるあいまいな行は表示されません。変更を囲む線に関して、Gitが持つコンテキスト感度の限界をどのようにテストしますか？
必要のない競合の解決は避けたいと思います。しかし、K＆Rに切り替えることで節約できる潜在的な競合の数と、それがもたらす追加のコンテキストをテストする方法が必要です。
これまでのところ、Gitは賢すぎて、些細な例にだまされることはできません。
どんな助けでも大歓迎です。前もって感謝します。
したがって、これはこれまでの証拠として私が見つけた最も近いものです。
http://git.661346.n2.nabble.com/Bram-Cohen-speaks-up-about-patience-diff-td2277041.html
電子メールは、Git の「忍耐」アルゴリズムの目的について議論しています。その中で Bram は、余分な一致行が、大きなパッチを含むかなり複雑なマージの場合にのみ、解決するのが難しい厄介な競合を引き起こす可能性があることを説明しています。言い換えれば、単純な不自然な例では、この動作を示すことができません。
彼は、結果に影響を与える End のようなことについても言及していますが、左中括弧を独自の行に配置すると、余分な一致行の数が増加し、これらの競合の可能性が高くなる可能性があると推測するのはある程度理にかなっています。
これは鉄壁ではないと思いますが、この理論にはある程度の信憑性があります.
したがって、「一意の行」は、「重要でない行」の単純な言語間プロキシです。
この議論では、この引用が際立っています。基本的に、コンテキストを提供するはずの重要な行であると私たちが感じていることを一致させているためです。ただし、ブレース自体は重要ではなく、コンテキストを提供しません.
あなたやあなたのチームが他の何よりも読みやすい標準を選択してください。ソース管理システムが今日どのように動作しても、明日はより良く動作しますが、コードは長い間チェックインした状態のままです。
K&R と B&D の両方が大量に混在する大規模なプロジェクト (200 以上のコード ファイル) がいくつかあります。Git、リファクタリングに夢中な開発スタッフ、および「1 日に数回」のリベース動作をほぼ 2 年間行った後、コーディング標準の問題が原因で競合が発生したことは一度もありません。したがって、どちらか、または両方を選択するか、どちらも選択しないでください。それは問題ではありません。